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ABSTRACT 


This report presents a method for translating operational data processing 
requirements into specific criteria for use in selecting, validating or 
evaluating computer operating systems. The criteria have been structured 
on the bcjs of an integrated functional classification structure applicable 
to the executive/control functions, system management functions and data 
manipulation functions of currently available operating systems. In concert 
with the methodology presented, a checklist form is included as an aid to 
developing selection criteria for particular applications. A diagram of 
the functional classification structure is also included. 
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SECTION I 
INTRODUCTION 


1.1 Purpose 

This report is the second of a series currently being produced by The COMTRE 
Co,poration for the Electronic Svstems Division of the Air Force Systems Command. 

The first report of this series, ESD-TR-70-377, presented an integrated functional clas¬ 
sification structure applicable to the executive/control functions, system management 
functions, and data manipulation functions of currently available commercial operating 
systems. A third report will establish validation requirements for major computer 
operating systems. 

In this report, criteria have been developed within the hierarchical structure 
of the functional classification presented in ESD-TR-70-377. Along with these criteria, 
methods for establishing a relationship between the criteria and operational require¬ 
ments have been delineated for each criterion or group of associated criteria. These 
methods are intended to aid in specifying operating system requirements and preparing 
operating system specifications. 

The analysis was based upon the following considerations relating to system speci¬ 
fication practices: 

1. Frequently criteria can be specified but are not; this is usually an 
oversight due to the lack of a comprehensive list of system 
specifications. 

2. Each user tends to specify details for an area in direct proportion to 
his knowledge of that area; frequently, certain functions are slighted 
due to a lack of expertise in that area. 

3. Features of aesthetic value, though not firm requirements, can often 
u_ specified to further enhance system usage. 

4. The level of detail included within a specification con vary according 
to the intended purpose of the specification. 

The method developed by this analysis provides a requirements checklist which 
will reduce the lack of specification due to oversights. Further, the requirements 


1 




checklist is keyed to references which will provide users information for areas in which 
they may not be experienced. And finally, the requirements checklist and references 
are structured into several levels of detail. While it is quite likely that the level of 
detail will vary for each section of a specification, the structure of the checklist is 
such that the required level of detail for each section can be reached in a methodical 
manner. 

During the preparation of this report, the use of the requirements checklist and 
associated .eferences as an aid in e'" ,i " r onosed systems became apparent 
During the evaluation process the proposed operating system design can be compared 
against the system functional structure included within the checklist to ascertain com¬ 
pleteness. Then, by using the reference material. the methods which appear to be 
most applicable to the given problem and to best satisfy the operational requirements 
can be systematically determined. The entire checklist and references can be used in 
this manner; however, levels three and four appear to be the most appropriate for 
detailed evaluation. 

1.2 Scope 

The analysis in this report relates operational performance requirements to specific 
operating system requirements for executive/control functions, system management 
functions and data manipulation functions. Requirements are related to functions in 
terms of specific criteria for performance specification or evaluation. 

This report is presented in three sections with one supporting attachment. Sec¬ 
tion 2 presents a description of the techniques identified for deteimining operating 
system performance requirements. Section 3 presents the selection and evaluation 
criteria accompanied by explanatory references. Finally, a diagram depicting on 
overview of the operating system functional c*ossification structure corresponding to 
the checklist levels of detail is attached to this report. This diagram can be used cs 
a reference by personnel using the checklist to determine the association of the area 
in which they are working with the total classification structure. 
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SECTION II 


SPECIFICATION AND EVALUATION GUIDELINES 

2.1 Operating System Requirements Identification 

The techniques for determining operating system performance requirements can 
best be described as a procedure consisting of three to six steps. The first step consists 
«f evaluating the system environment. The second step consists of making basic system 
performance decisions. The third step consists of specifying performance criteria at a 
general level. The fourth, fifth and sixth steps amplify the third step at successively 
greater levels of detail. 

The total number of steps used during the selection of any particular operating 
system varies depending upon t f e permissable level of detail for the particular selection. 
The appropriate level of detail, in turn, varies with the circumstances of a particular 
application of the selection technique. For example, if the technique is being applied 
for the purpose of developing on operating system specification for a known hardware 
configuration then the specification will probably be of a more detailed form than if 
the specification were prepared as part of a hardware solicitation. 

2.2 Evaluation of the Environment 

The first step in the procedure discussed above is an evaluation of the environ¬ 
ment in which the operating system will be expected to perform. This step docs no 
more than establish an overview of the intend of the system procedurally. It is, 
however, very important since it establishes the framewcrfc upon which most further 
decisions will be mode. 

Often, the essentia! capabilities necessary to satisfy a set of requirements can 
be envisioned conceptually or are known from post experience. In such coses an 
evaluation of this information will determine the basic characteristics of the operating 
system environment. In any case, however, the following environmental character¬ 
istics should be determined: 

o First, determine the salient character tics of the processing 
modes which must be supported by the system. 
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It is very important in the further development of specific requirements to char¬ 
acterize system processing as real-time, batch, remote batch or time-sharing. It Is 
also necessary to determine if a mixture of processing modes must be supported, e.g., 
time-sharing and batch, real time and batch, etc. 

If the system is to perform computation that controls an ongoing process and 
delivers its outputs (or control inputs) not loter than the time needed for effective 
control of t l e process, then the processing mode is real time . This mode is usually 
ass dated with air defense systems, ballistic missile checkout/control, space vehicle 
checkout/control, etc. 

Most operating systems with the exception of some real-time processing systems 
allow the processing of jobs submitted to run independently of events outside the 
system on a deferred or time-independent basis (e.g., whenever the processing work¬ 
load is light). If the system is to support this type of processing, then the processing 
mode is botch . Many times this feature is required for remote sites as well as the nor¬ 
mal local site usage which means that the environment will also consist of a remote 
botch mode. 

Finally, if the system is to support concurrent processing capabilities for several 
users via multiple terminals, then the mode is time-sharing . 

o Second, develop an application program scenario. 

Although it has been determined by defining the processing mode that the appli¬ 
cation programs will be either botch/fime-sharing/real time, there should also be 
many other known application support requirements. To formalize these requirements 
if is best to examine known applications or develop concepts relative to anticipated 
applications. Since the specification of requirements for on operating system depends 
to a large extent upon the satisfaction of application program requirements, if is 
necessory to develop an operational scenario for the application programs. This 
scenario should include such items as program descriptions, estimated program sizes, 
response time requirements, concurrency requirements, interaction requirements, inter¬ 
dependency requirements, operational hierarchy requirements, anticipated or known 
structural requirements, expected utilization, and unique features r requirements ex¬ 
hibited by the application programs. 
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o Third, delineate all known hardware configuration information. 

This consideration is simplified in areas where the hardware is known and a new 
operating system is being acquired. However, when a total hardware and software 
system is being acquired, as is often the case, this delineation can be quite difficult. 
Nevertheless, specification or postulation of a detailed hardware configuration should 
be accomplished if possible, since knowledge of a configuration is requisite to devel¬ 
opment of many specific criteria. The delineai.’an of peripheral and communication 
devices is important as well as that of the processor configuration and the size or 
estimated size of the system. Within the framework of Section III of this report, 
reference is sometimes made to the size^ of the system as a guide to applicable re¬ 
quirements. Previous analyses of various oper. ring systems has shown that the occur¬ 
rence of several features tends to be closely related to the system size. 

The considerations listed above define the operating system environment, an 
application program scenario, and a specific hardware configuration. From this 
information, further decisions can be made regarding the expected performance of 
the system. 

2.3 Basic Performance Decisions 

As discussed above, there are certain decisions that should be made concerning 
the expected performance of the operating system. These decisions provide an in¬ 
sight into the total operational philosophy of the system and directly affect the appli¬ 
cability of specific requirements for specification ot evaluation. The following topics 
and J: scussions are designed to aid in making these decisions, 
o Processing performance 

Once the operating system environment has been established and the applications 
delineated, the next step shouH be to consider the need or lack of need for multi- 

* For the purposes of this report, system size corresponds to the Operating System levels 
presented in ESD-TR-70-6.5, Survey and Analysis of Major Computing Operating 
Systems, 31 Jcnuary 1970. These levels are: 

- smoll scale computers with core storage generally less than 32K bytes (where 
a byte consists of 8 bits); 

- medium scale computers with core storage ranging from 32K bytes to 132K 
bytes; and 

- large scale computers with core storage in excess of 132K bytes. 
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program processing, if the application scenario previously developed indicates that 
the operating system must support concurrent core residence and processing of multiple 
programs, then multiprogramming is required, if there appears to be reason to expect 
that simultaneous execution of programs is required then this may dictate the consid¬ 
eration of a multiprocessor hardware configuration. However, if requirements indicate 
that concurrency of application operation is not an absolute prerequisite, then serial 
processing may also be acceptable. 

The type of processing environment (batch, time-sharing, real time) can affect 
the operational philosophy of the system in the following respect. In a batch pro¬ 
cessing syste; . individual job throughput may not be of prime concern due to the 
usual background nature of the jobs supported; therefore, maximum utilization of 
system resources is usually more important than the amount of system overhead incurred. 
On the other hand, a time-sharing system would strive for a balance between resource 
utilization versus incurred overhead due to the requirement to interact and support 
multiple users. Finally, a real-time processing system usually stresses low overhead 
and requires maximum job throughput with resource utilization being of only secondary 
concern. 

Therefore, tradeoff decisions need to be made relative to serial versus multi¬ 
program processing, and overhead versus throughput versus resource utilization of the 
processing system. 

o Mode of operational support 

There are two basic modes of operation supported by operating systems. These 
are: continuous operational capability over an extended period of time and scheduled 
operation over a fixed period of time, e.g., eight-hour shift per day. 

The major difference between these modes of operation is the criticality of the 
processing supported. Continuous operation is not normally a requirement for batch 
processing while it is almost mandatory for real-time processing and may be highly 
desirable for some time-sharing systems. 

The determination of which of these modes of operation is to be provided by the 
system will aid in the determination of how comprehensive the error recovery require¬ 
ments will be, whether on-line maintenance or periodically scheduled off-line main¬ 
tenance will be required, and whether on-line or off-line program checkout will be 
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necessary. If the system is to provide the capability for continuous support with very 
little down time, then comprehensive error recovery procedures, on-line maintenance, 
and on-lint program checkout should receive definite consideration. This decision 
can also affect the hardware configuration since equipment redundancy, either on -line 
or off-line, is frequently required for continuous support, 
o Type of user personnel 

When it is known that the system must interface with and accomodate users 
with limited programming interests, such as in a general time-sharing system, greater 
attention should be paid to the area of diagnostics and system communication. This 
attention should focus upon the ease of usage, clear and simple messages, and clear 
and simple instructions. 

If the system is real-time, the user can usually be assumed to be a sophisticated 
assembly or machine language programmer familiar with the internal organization of 
the computer; and although diagnostic and debug features are very important, they 
do not require the level of explanation and simplicity required for general time¬ 
sharing usage. 

o Type of checkout supported 

If a system is to provide continuous operational support, then a method should 
be considered for allowing application program checkout concurrent with on-line 
operations. This would probably involve the utilization of a special checkout mode 
and therefore require special operating system support. This feature is required mest 
frequently in real-time processing systems and is usually also standard in time-sharing 
processing systems. 

o Operational philosophy of the system 

The question of manual intervention versus automatic decision making must be 
considered. Will the operating system be higl 'y dependent upon operator interven¬ 
tion or will the operating system be as independent as possible requirr very little 
operator intervention? 

o Maintainability 

Certain basic decisions should be made concerning the capabilities to maintain 
the system operationally, e.g., the ease of updating, changing, deleting, generating, 
and initializing, and the support to be provided for changing hardware configurations. 
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o Reliability 

This function is important to all sy„.ems but the real-time environment usually has 
the most stringent requirements in this area. Specifications for this area should con¬ 
sider the degree of editing., error checking, fault isolation, operational degradation, 
etc., that will be required by the operating system, 
o Expandability 

Finally, it should be determined if the operating system may be required to per¬ 
form additional functions in the future above and beyond those described within the 
application scenario. This decision can affect the selection of certain requirements 
which will ease the required operational transition ai a later date. 

When all of these considerations have been assessed, the next step is to select 
the requirements that will best satisfy the decisions made. 

2.4 Use of the Selection and Evaluation Criteria 

The third through sixth steps used in selecting operating system requirements are 
found within Section III of this report. Section III contains requirements checklists 
and references to aid in the selection of requirements for an operating system or for 
the evaluation of a proposed operating system. These requirements checklists are 
constructed within the framework established by the Operating System Functional 
Classification Structure. The entire structure as it relates to requirement specifica¬ 
tion is depicted in Attachment 1 to this report. 

As shown in the attachment, the major operating system areas consist of: 

1) Executive/Control Functions, 2) System Management Functions, and 3) Data 
Manipulation Functions. Each of these major functionH areas is broken down into 
hierarchical levels of functions contained within the major functional areas. For 
example, within the major functional area Executive/Control the first level grouping 
is: 1.0 JOB MANAGEMENT, 2.0 DIAGNOSTIC ERROR PROCESSING, and 3.0 
PROCESSING SUPPORT, while the second level grouping consists of such functions 
as 1.1 JOB CONTROL, 1.2 I/O CONTROL, 1.3 SYSTEM COMMUNICATION, 1.4 
RECOVERY PROCESSING, 2.1 HARDWARE ERROR CONTROL, 2.2 PROGRAM ERROR 
CONTROL, etc. Each lower level is a more detailed functional breakdown of the 
functions of the preceding higher level. In certain functional areas this structure 
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is subdivided info only two levels, while in other areas it is subdivided into as many 
as four. 

Similarly, the requirements checklist has also been structured by the same hier¬ 
archical levels and are presented for each of the three major functional areas (Execu¬ 
tive/Control, System Management, and Data Manipulation). 

The presentation of the functions in the group level format provides a procedural 
structure which allows personnel using the checklist to perform a step-by-step progression 
to the level of derail required for a particular application. Also, this type of structure 
provides a total system overview at each level. This is highly important in developing 
an understanding of the entire operating system structure. With this in mind, the 
attached diagram illustrating an overview of all levels of the hierarchical structure 
will also enable the user to relate each particular function to the composite structure. 

The level to which the requirements are selected for specification is dependent 
upon many factors and an absolute rule can not be applied to determine the number of 
levels that should be used. In many cases the level to which the requirements can be 
specified is dependent upon the detailed knowledge or information available for 
particular system's applications. In other cases the level of specification may vary 
according to particular circumstances. 

During the preparation of operating system specifications, it can be generally 
assumed that for a known hardware configuration the entire checklist should be used. 

In preparing a specification for an unknown hardware configuration, the first two 
levels are most appropriate, while caution should be exercised in specifying the 
requirements appearing in levels three and four. The reason for this is that many of 
the methods used to implement operating systems are directly related to the hardware 
upon which the operating system functions. Hence, many operating systems perform 
the same function using different methods. Consequently, delineation of specific 
requirements for operating system functions may lead to a choice between different 
implementation methods, the specification of either of which would be overly re¬ 
strictive for a competitive procurement. 

A word of caution should be interjected at this point: The requirements check¬ 
list is to be a working document used by personnel to indicate requirements for an 
operating system. A detailed review by the personnel preparing the final solicitation 
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document must be conducted to detect the specification of any improper or superficial 
requirements. The danger in using a checklist of the type proposed is that criteria 
can be specified, when in fact the criteria are not needed. Consequently, the user 
must continually recognize that valid justification is still necessary prior to the 
selection of any requirement. 

Finally, it is a near certainty that although this is a fairly comprehensive check¬ 
list, there will still be some user requirements or methods of stating requirements other 
than those that appear within the checklist. These requirements, when they occur, 
should first be incorporated within the system specification by the user and along with 
available reference material should also become a permanent part of an updated check¬ 
list. This will insure that the checklist remains a comprehensive tool in performing 
operating system specification, selection and evaluation. 

A user can use his own discretion in how he designates (e.g., yes, no, manda- 
tory, optional, etc.) that a requirement is a criterion for his particular system. An 
example of this using page 44 (1.1.1 SCHEDULING) of this report as reference is as 
follows: 

The user has an extremely complex scheduling requirement (several jobs compet¬ 
ing for execution), so he would place a "yes" by requirement (a). Since he has 
several jobs in competition, he would place a "yes" by requirement (f), and if he 
knew the number of possible jobs in contention, he would fill in the blank within 
requirement (f), etc. 

In many cases a requirement can be specified as "Mandatory" and this can be 
used as a designator by the user, or a requirement may be specified os "Optional" 
to mean that if a system has this feature, it is an added feature and will be a weighting 
factor during final system selection. 
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SECTION III 

SPECIFICATION AND EVALUATION CRITERIA 


3.1 Introduction 

This section presents the operating system requirements checklist discussed in 
Section II. The checklist consists of a column of requirements applicable to each 
functional classification area, followed by three columns entitled "Reference", 
"Initial", and "Extended." 

The "Reference" column contains reference numbers adjacent to the requirement 
or requirements to which they are applicable. These reference numbers coincide with 
the list of references on the facing page. These references will aid in the determin¬ 
ation of whether the requirement should be specified or is applicable for specification 
for a particular operating system. As with the requirements checklist, the references 
are intended to be open-ended. The references should be extended as users identify 
additional considerations. 

The column entitled "Initial" is to be used by personnel using the checklist to 
indicate whether a requirement is a criterion for me initial phase of the partici ’ar 
operating system which is being specified; while the column entitled "Extended" is 
to be used to indicate requirements that will be included within the operating system 
at a later date but are not required for initial installation. It should also be noted 
that within certain listed requirements blanks are available for inserting parameters 
when their values are known. 

3.2 Requirements Checklist - Part I - Executive/Control Functions 

The following subsections present specification and evaluation criteria for the 
components of the operating system that maintain real-time execution control over 
the system environment. 

3.2.1 First Level of Detail (Port I - Executive/Control Functions) 

This subsection covers the following first level executive/control functions: 

1.0 JOB MANAGEMENT 

2.0 DIAGNOSTIC ERROR PROCESSING 

3.0 PROCESSING SUPPORT 
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OPERATING SYSTEM 


REQUIREMENTS CHECKLIST 


1.0 JOB MANAGEMENT 

(a) Batch processing support m ist be provided. 

(b) Real-time support must be provided. 

(c) Time-sharing support must be provided. 

(..y Multiprogramming support must be provided. 


Reference 


(e) Multiprocessing support must be provided for 
processors. 

















[ 


1.0 JOB MANAGEMENT 

Reference : 

1. The job management function is responsible for the initiation, scheduling, 
monitoring, and control of system operations for all jobs submitted to the 
system. In this context, a job encompasses all of the programs required 
for the execution of a given application. The job management subfunc¬ 
tions consist of: job control, input/output control, system communication, 
and recovery processing. 

2. The operational environment (batch, real-time, time-sharing) of a system 
is directly established by the intended system applications. 

3. Multiprogramming is a technique that attempts to maximize computer 
throughput by interleaving the execution of two or more programs. Nor¬ 
mally, multiprogramming is not a requirement as long as system throughput 
requirements can be met in a non-multiprogrammed manner. However, 
some systems require multiprogramming as a firm operational requirement 
without regard to throughput. These systems are normally those that combine 
two or more processing environments (such as batch and real-time process¬ 
ing) or those that are communication based systems using multiple terminals 
and requiring multiprogramming techniques due to the large number of con¬ 
current messages received. 

4. This criterion is entirely dependent upon the hardware configuration and 
can only be specified when the configuration is known. 



>1 
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OPERATING SYSTEM 


REQUIREMENTS CHECKLIST 


2.0 DIAGNOSTIC ERROR PROCESSING 

(a) The system must provide hardware error control. 

(b) The system must provide program error control. 

(c) The system must provide interface error control. 

(d) The system must provide error recovery procedures. 


REQUIREMENTS 


Reference Initial I Extended 
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2.0 


DIAGNOSTIC ERROR PROCESSING 


Reference: 

1. The diagnostic error processing function is responsible for recognizing hard¬ 
ware, program end interface errors. Recognition is usually based upon hard¬ 
ware interrupts or program testable switches. The function also supports the 
diagnosis and resolution of error conditions. 

2. This criterion is highly dependent upon the hardware configuration and can 
only be specified in detail when the hardware configuration is known. 

3. This criterion is rarely specified. However, it may be necessar> to specify 
it when there will be a iarge amount of program testing in a batch processing 
or time-sharing environment or if the system operates in an on-line real-time 
environment. 

4. Usually any interface that can exhibit control, introduce control, request 
control or initiate an executive function should be edited. The editing 
performed is generally ba'ed upon system defined format constraints, 

5. Error recovery routines are usually provided with a system and they may be 
augmented by the installation during system generation. Augmentation or 
redesign of error recovery routines is most frequently found in real-time 
environments. This function should be specified for all processing systems. 
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OPERATING SYSTEM 


REQUIREMENTS 


(a) 

(b) 

(c) 


REQUIREMENTS CHECKLIST 

3.0 PROCESSING SUPPORT 

The system must provide a timing service. 

The system must provide testing/debugging service. 

The system must provide a logging and accounting 
service. 


Reference 


Initial 


1 

2 

3 


Extended 


(d) The system must provide system description maintenance. 






















3.0 


PROCESSING SUPPORT 


Reference: 

1. The processing support functions consist of supervisor routines which may be 
called upon to accomplish a variety of miscellaneous services for an application 
program. In general the services are utilitarian in nature and provide conven¬ 
ient, rather than necessary, functional sjpport. 

2. Most systems have an internal timing device which provides timing services to 
application programs. A few systems, to reduce the size of the resident super¬ 
visor, only include these services as an option during system generation. This 
feature is highly desirable in a real-time processing system and frequently 
occurs in both the batch processing and time-sharing environments. 

3. In a real-time environment testing/debugging service specifications should take 
advantage of any specially provided hardware processing modes. 

4. This criterion is rarely specified. However, it may be advisable when a single 
set of app'ication and/or system programs are to be executed using two or more 
hardware configurations so that the programs may tailor themselves to the 
specific hardware or software environment. 
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3.2.2 Second Level of Detail (Part I - E xecutive/Control Function s) 

This subsection covers the following second level executive/control func¬ 
tions: 


1.1 JOB CONTROL 

1.2 I/O CONTROL 

1.3 SYSTEM COMMUNICATION 

1.4 RECOVERY PROCESSING 

2.1 HARDWARE ERROR CONTROL 

2.2 PROGRAM ERROR CONTROL 

2.3 INTERFACE ERROR CONTROL 

3.1 TIMING SERVICE 

3.2 TESTING/DEBUGGING SERVICE 

3.3 LOGC1NG AND ACCOUNTING 

3.4 PROGRAM ACCESSIBLE SYSTEM DESCRIPTION MAINTENANCE 
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OPERATING SYSTEM 


REQUIREMENTS CHECKLIST 


Reference 


REQUIREMENTS 


Initial Extended 


1.1 JOB CONTROL 

(a) The system must provide support for the concurrent 
execution of up to_batch jobs. 

(b-c) Batch support must be provided for: 

(b) central site job entry, 

(c) remote job entry. 

(d) The system must support_remote job entry batch 

terminals. 

(e) The system must provide support for the concurrent 

execution of up to_real-time jobs. 

(f) The maximum service time for a real-time request 
under average load conditions is 

(g) The maximum service time fora real-time request 

under maximum load conditions is_. 

(h) The system must provide control for real-time jobs 
initiated by clock interrupts. 

(i) The system must provide support for the concurrent 

execution of up to_time-sharing jobs. 

(j) The system must support, at a maximum, simultaneous 
submission of jobs from terminals. 

(k) The system must support, on the average, simultaneous 

submission of jobs from_terminals. 

(l-m) The system must provide a response to interactive 
terminals within a time frame 

(l) of during maximum load conditions, 

(m) of during average load conditions. 























1.1 


JOB CONTROL 


Reference: 

1. Do not overlook any future expansion requirements in this area since it will 1 

- obably be more economical to include these requirements in the basic 

system rr l her than ro change the system at a later date. 

2. While frequently employed for evaluation, this criterion is rarely speci- i 

fied. However, it may be necessary under the following circumstances: ' 

a. enough information is known about the real-time environment 
to determine the number of independent real-time processes/ 
interrupts requiring near-simultaneous servicing 

b. sufficient information is known about the hardwai i config¬ 
uration, throughput requirements, and projected batch , 

processing load to dictate a level of accuracy. 

3. This criterion is entirely dependent upon the hardware configuration and can 
only be specified when the configuration is known. 

4. This criterion should be specified when system response time requirements are 
known. 

5. This criterion should be specified fora time-sharing system. I 
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1.2 


I/O CONTROL 
Reference: 


1. System control over the activity of input and output devices is a characteristic 
feature of third-generation operating systems. This control is maintained for 
two separate reasons. First, it simplifies the work of the application program¬ 
mer since he need not be concerned with the intricate details of programming 
for a variety of channel and device characteristics. This upgrades the overall 
effectiveness of the programming staff since a standard and well defined 
approach, rather than a number of widely varying approaches, is always used 
to interface with I/O devices. Secondly, since the system is in control ot 
I/O activity, the application program need not be alerted to process I/O 
interrupts. • 

2. Future expansion requirements should be factored into the quantity of each 
device to be supported. 

3. I/O scheduling is the process of acknowledging a request for I/O services and 
initiating the physical input or output operations to satisfy the request. Requests 
for service may be processed immediately or they may be serviced according to 

a queuing scheme. In the latter case, queues are provided to hold requests for 
channel or device services. This criterion should be specified for all system 
environments. 

4. This criterion should be specified for either a time-sharing or remote batch 
processing system. It may only be specified in detail when the hardware 
configuration is known. 

5. If it is possible that all remote terminals will be interacting or functioning 
with the system at any particular time, then the number of rer ote terminals 
will equal the number requiring concurrent activity. 

6. This value should be de' 'srmined by the anticipated utilization under peak 
loading conditions. 

7. This criterion is highly dependent upon the hardware configuration and can 
only be specified in detail when the hardware configuration is known. 
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OPERATING SYSTEM 


REQUIREMENTS CHECKLIST 


Reference Initial Extended 


1.3 SYSTEM COMMUNICATION 

(a) The system must permit up to_operator terminals/ 

displays. 

(b) The system must permit up to_user terminals/ 

displays. 

(c-f) The system must support the following types of 
operator and user communication devices: 

(c) card reader, 

(d) console typewriter, 

(e) typewriter-CRT display, 

(f) typewriter-printer. 

(g) The system must provide device independent communi¬ 
cation formats. 

(h) System startup must be provided. 
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SYSTEM COMMUNICATION 


Referen ce: 

1. System communication incorporates all of the functions involved in the exchange 
of information between the user or the computer aerator and the operating system. 
The communication may be oriented either to controlling the execution of scheduled 
jobs within the system or to configuring system components and monitoring system 
status. 

2. This criterion is dependent upon the hardware configuration and can only be 
specified in detail when the hardware configuration is known. Potential 
expansion requirements should also be considered. 

3. The use of a card reader as a communication device is usually only associated 
with local or remote batch processing. 

4. Typewriter printers and typewriter-CRT displays can be associated with both 
time-sharing and real-time environments. 

5. Providing device independent communication formats entails much planning 
in the design phase; however, it is quite worthwhile to the user. This feature 
allows any communication device to be substituted for another device type 
without greatly affecting operation. Furthermore, this method of format 
standardization can be an economical factor in user job and program prep¬ 
aration. Consequently, it should be seriously considered during the develop¬ 
ment of specifications or during the e> :!*jation of system proposals. 








OPERATING SYSTEM 


REQUIREMENTS CHECKLIST 


Reference 


REQUIREMENTS 


Initial Extended 


1.4 RECOVERY PROCESSING 

(a-b) The system must provide checkpoint/restart facilities 
at the following levels: 

(a) program, 

(b) system. 

(c) The system must provide restart for all suspended 
programs. 
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.4 


RECOVERY PROCESSING 


Reference: 

1. Checkpoint/restart facilities are normally invoked whenever error processing 
routines have analyzed an error and determined that execution should be 
resumed from an earlier point in the processing cycie. Consequently, check¬ 
point/restart usually supplements normal error recovery operations and should be 
considered for specification in all system environments. 

2. Checkpointing may be performed at either the system level or the program level. 
Only in rare circumstances are both provided. The system level checkpoints 
the entire system whereas the program level only checkpoints a single program. 
Consequently, in a real-time system checkpoint/restart facilities are generally 
initiated at the system level rather than the program level. In a batch pro¬ 
cessing or time-sharing system, on the other hand, checkpoir.'/restart facilities 
are most likely to be initiated at the program level. 

3. When checkpointing is performed at the program level, a checkpoint rm y also 
be used to temporarily suspend and later resume an executing program in order 
to permit execution of one or more programs. 
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HARDWARE ERROR CONTROL 


Reference : 

1. It Is usually necessary to specify this criterion when proposing an extensive 
error recovery scheme for a particularly complex system. 

2. Generally, error correction is performed by retrying a failing operation and, if 
this fails, relying upon an alternate method of accomplishing the operation. 

3. Usually, if error correction can be satisfactorily performed, notification of the 
error is not requii«d. However, if the error can not be corrected, some form of 
error notification should be directed to the operator and to any affected inter¬ 
active user. 

4. System recovery from hardware errors can be associated with systems that support 
reconfiguration either through standby redundancy, replaceable modules and 
devices, or a degraded (fail soft) mode of opera; ion. These functions are most 
frequently found in medium-to-large scale systems supporting a real-time 
environment where full time operation is required. 

5. Indications of CPU errors, I/O device error;, I/O channel errors, parity errors, 
and power failures are generated by almost every hardware system. 

6. The recognition of co-processor errors is only significant in a multiprocessor 
configuration. Generally, one of the rio^-failing processors v/ill initiate 
diagnostics to determine the cause of the failure, the extent of the do^uge, 
end the recovery procedures that can be invoked. Error recovery for t, multi¬ 
processor configuration is more complicated fby an order of magnitude) than 
for uni-processing systems. 
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OPERATING SYSTEM 


REQUIREMENTS CHECKLIST 


REQUIREMENTS 


Reference Initial Extended 


2.2 PROGRAM ERROR CONTROL 

(a) The system must provide for program error correction. 

(b) The system must provide program error notificai.on. 

(c) The system must provide controlled abnormal program 
terminations 

(d-|) The system must detect the fd‘owing types of error: 

(d) arithmetic errors, 

(e-g) instruction errors: 

(e) invalid instruction, 

(f) unsupported instruction, 

(g) privileged instruction, 

(h) invalid address errors, 

(i) storage protection errors, 

(j) invalid data errors. 























2.2 


PROGRAM ERROR CONTROL 


Reference; 

!. Almost all './stems recognize program errors occurlng in user programs and assume 
control to prevent the system from being adversely affected. The user is frequently 
allowed to supply his own error handling routines for certain types of errors, such 
as arithmetic and data errors. 

2. Program error notification should be considered for a time-sharing system since 
the interactive user can frequently determine the corrective action that should 
be taken. In batch processing the error is normally logged and on-line notifi¬ 
cation is not normally performed. In the real-time environment when an error 
occurs in an operational program, it is usually desirable for notification to be 
made directly to the console operator. 

3. This function is highly desirable in batch and time-sharinp systems. In a real¬ 
time environment, a form of error recovery, rather than abnormal termination, 
should be considered. 

4. These criteria are dependent upon the hardware configuration and can only be 
specified in detail when the hardware configuration is known. 

5. There are several different types of instruction errors that a system should 
recognize and distinguish. An invalid instruction is one that is not a part 
of the hardware's instruction repertoire. The normal error procedure should 

be to terminate the offending program. An unsupported instruction error occurs 
when a computer has optional instruction sets. Normally a programmed procedure 
can be used to simulate the optional instruction. Privileged instructions are used 
by most third generation systems to reserve a part of the instruction set for the 
sole use of the supervisory programs. By controlling the use of these instructions, 
aoplication programs are much less likely to inadvertantly damage the software 
system. The recognition or detection of an attempted use of one of these 
instructions by an application program should cause operator notification and 
possibly job termination. 

6. Invalid addressing errors are detected by mosl' systems when either the address 
does not physically exist within hardware storage or if it lies out of an appli¬ 
cation program's assigned working area. Unauthorized attempt to access OS 
resident areas or other ur,er areas should be detected and the offending program 
should be terminated. In a shared computer system (batch or time-sharing), 
repeated occurences should be brought to the attention of the operator. Time¬ 
sharing systems that process classified or private information should always 
storage protect this information and notify the operator of any violations. 

7. It is usually impossible to determine invalid data content unless the user has 
specified limit values wi f hin which the data should occur. However, hardware 
detection can be used for detecting invalid data parity and adherence to device 
data formatting requirements. 
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OPERATING SYSTEM 


2.3 


REQUIREMENTS CHECKLIST 


Reference 


INTERFACE ERROR CONTROL 


(a) The system must edit operator key-ins. 

(b) The system must edit input stream control commands. 

(c) The system must edit remote terminal communications. 

(d) The system must edit program to system linkages. 




















INTERFACE ERROR CONTROL 


Reference: 

1. All processing system environments provide a form of operator communication. 
Most systems thoroughly edit and validate each operator input command prior 
to attempting to execute it since the failure to do so could result in a system 
failure. Consequently, serious consideration should be given to this criterion. 

2. This criterion should be specified for a batch processing or time-sharing environ¬ 
ment. 

3. This criterion should be specified for time-sharing and remote batch processing 
environments. 

4. This criterion is highly recommended for time-sharing and batch processing 
systems. It's usefulness in a real-time environment is somewhat questionable 
since real-time programs should be thoroughly validated prior to operational 
processing. 
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3.1 


TIMING SERVICE 


Reference: 

1. These features are highly desirable in a real-time processing system and are quite 
useful in time-sharing and batch processing environments. Implementation, how¬ 
ever is dependent upon the availability of a timing device. 

2. Real-time clock services are generally required for any environment in which 
the time of day will affect the processing workload. For example, in batch 
processing a time of day is frequently used as a deadline by which some pro¬ 
cessing jobs must be completed. In real-time systems, it may be used either 
for job scheduling or for distinguishing event occurences (e.g., message time- 
stamping). Time-sharing systems have no particular requirement for a real¬ 
time clock. 

3. Interval timers are generally required in a real-time environment in which 
execution scheduling is based upon a periodic interval (e.g., polling of 
communication lines). Interval timing services are also used by most time¬ 
sharing environments to control the execution time allotted to each user. 

Interval timing service can also be incorporated within all systems as a 
debugging aid. One method of use is for an application program to set a 
time limit on the performance of a loop. If the time expires prior to loop 
completion or exit, then this indicates that something is wrong within the 
loop. Also, this function is sometimes used by systems to detect I/O devices 
that fail to respond within a certain designated time period. 
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OPERATING SYSTEM 


REQUIREMENTS 


REQUIREMENTS CHECKLIST 


Reference Initial Extended 


3.2 TESTING/DEBUGGING SERVICE 

(a) The system must provide storage dumps. 

(b) The system must provide tracing facilities. 

(c) The system must provide a special test/debug 
operating mode. 
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TESTING/DEBUGGING SERVICE 
Reference: 


1. This criterion should be specified for all processing systems. 

2. Tracing facilities are usually most extensive in a time-sharing system although 
they are also quite useful in testing batch and real-time programs. Specifica¬ 
tion of the criteric ; should be dependent upon the anticipated level of pro¬ 
gram testing that will be performed. 

3. This criterion is highly desirable in both a batch and real-time processing 
environment. In real-time processing, it may permit some program testing 
while the system is actually "on-line," or it may allow the simulation of a 
real-time environment when the system is "off-line." It is also extremely 
useful in a batch processing system where a high degree of program testing 
occurs. In this area, it frequently takes the form of a set of pre-specified 
actions that can be invoked when a program error occurs. These actions 
override the system's standard abnormal termination processing capabilities. 
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OPERATING SYSTEM 


REQUIREMENTS CHECKLIST 


Reference 


REQUIREMENTS 


Initial Extended 


3.3 LOGGING AND ACCOUNTING 

(a-c) The system must maintain: 

(a) job charge information, 

(b) error statistics, 

(c) system utilization statistics. 















3.3 LOGGING AND ACCOUNTING 


References : 

1. Batch processing and time-sharing operating systems normally require detailed 
accounting information on job execution time, device utilization, core utili¬ 
zation, etc. Consequently, this criterion should be specified ior these two 
environments. 

2. It is usually highly desirable to accumulate error statistics in order to iden¬ 
tify hardware devices that have a greater than normal frequency of intermittent 
errors. As a result this criterion should be considered for all processing 
systems. 

3. Though this criterion is rarely specified, it may be desirable to maintain system 
utilization statistics for relatively large and complex systems. These statistics 

in turn, can be examined to enable the system manager to tailor and tune various 
operating system functions to improve overall system performance. 
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OPERATING SYSTEM 


REQUIREMENTS 


REQUIREMENTS CHECKLIST 


Reference Initial Extended 


3.4 PROGRAM ACCESSIBLE SYSTEM 
DESCRIPTION MAINTENANCE 

(a) The system must maintain current system status infor¬ 
mation. 

(b) The system must maintain current system description 
information. 

(c) The system must provide for the extraction of system 
description information by a user program. 
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3.4 PROGRAM ACCESSIBLE SYSTEM DESCRIPTION MAINTENANCE 


References : 

1. Many batch processing and time-sharino ./stems maintain a certain amount 
of descriptive information in a superv'sor communication region that may be 
interrogated by an application program. Three types of information are 
likely to be maintained: system defining information, current system status 
information and individual job information. 

2. System status information may be of use to installation monitoring or account¬ 
ing routines tha* "•"e not built into the operating supervisor. Device status 
information (availability) is also extremely useful when an application 
program may we a number of different devices to accomplish its processing. 

3. This information is useful when there are general purpose programs or 
compilers in operation that have the capability of alternate modes of opera¬ 
tion based upon hardware and software status. For example, sort programs 
are usually designed to use all of the core area available. 
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3.2.3 Third Level of Detoil (Part I - Exe cutive/Control Functions) 

This subsection covers the foliov'irg third level exec jtive/control func 

tions: 

1.1.1 SCHEDULING 

1.1.2 RESOURCE ALLOCATION 

1.1.3 PROGRAM LOADING 

1.1.4 EVENT MONITORING 

1.1.5 PROGRAM TERMINATION PROCESSING 

1.2.1 I/O SCHEDULING 

1.2.2 DATA TRANSFER 

1.2.3 DEVICE MANIPULATION 
12.4 REMOTE TERMINAL SUPPORT 

1.3.1 SYSTEM STARTUP 

1.3.2 JOB CONTROL C' LMUNSCATION 

1.3.3 INPUT/OUTPUT . ,£AM CONTROL 

1.3.4 RESOURCE STATUS MODIFICATION 

1.3.5 SYSTEM STATUS INTERROGATION 

1.4.1 CHECKPOINTING 

1.4.2 RESTARTING 

2.1.1 ERROR CORRECTION (Hardware errors) 

2.1.2 ERROR NOTIFICATION (Hardware errors) 

2.1.3 ERROR RECOVERY (Hardwcre errors) 

2.2.1 ERROR CORRECTION (Program errors) 

2.2.2 ERROR NOTIFICATION (Program errors) 

2.2.3 PROGRAM TERMINATION 

2.3.1 OPERATOR KEY-IN EDITING 

2.3.2 CONTROL COMMAND EDITING 

2.3.3 REMOTE TERMINAL COMMUNICATION EDITING 

2.3.4 PROGRAM TO SYSTEM LINK VERIFICATION 

3.1.1 REAL-TIME CLOCK SERVICE 

3.1.2 INTERVAL TIMER SERVICE 

3.2.1 STORAGE DUMP CONTROL 

3.2.2 TRACING CONTROL 

3.2.3 SYSTEM TEST MODE CONTROL 

3.3.1 MAINTAINING JOB CHARGE INFORMATION 

3.3.2 MAINTAINING ERROR STATISTICS 

3.3.3 MAINTAINING SYSTEM UTILIZATION STATISTICS 

3.4.1 CURRENT SYSTEM STATUS INTERROGATION 

3.4.2 SYSTEM DEFINITION INTERROGATION 
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OPERATING SYSTEM 



REQUIREMENTS CHECKLIST 

Reference 


1.1.1 SCHEDULING 

1 

(a) 

The system must provide an algorithmic scheduling 
capability. 

2,7 

(b) 

The system must provide a time-initiated scheduling 
capability. 

3 

(c) 

The system must provide an event-initiated scheduling 
capability. 

4 

(d) 

The system must provide a program-initiated 
scheduling capability. 

5 

(e) 

The system must provide conditional scheduling. 

6 

(f) 

The system must recognize up to scheduling 

priority levels. 

7 

(g-k) 

Batch scheduling must be permitted from the 
following sources: 



(g) local input 51 ream, 

(h) remote input stream. 

8 


(i) an executing interactive job, 

9,5 


(j) an executing real-time job. 

9,5 


(k) another executing batch job. 

9,5 

(1) 

The system must provide scheduling for programs 
and/or subprograms which will be consistent with 

10 


the desired sequence of operations. 



REQUIREMENTS 


initial Extended 





















1.1.1 SCHEDULING 


Reference: 

1. The purpose of the scheduling function Is to select a job which is avail¬ 
able for processing and prepare it for execution. The function may be 
extremely complex, as in an extended multiprogramming system where 
several jobs may be simultaneously available for execution, or quite 
simple, as in serial processing systems where the order of programs in 
the input stream may dictate the execution sequence. Since most 
systems handle more than one type of processing mode, different sch¬ 
eduling philosophies are used for the real-time, time-sharing, and 
batch processing applications. 

The greatest variation in the implementation of the scheduling facility 
exists in the handling of batch processing. The most elementary approach 
is to schedule each job for execution in the sequence of its occurence in 
the input stream. When a system has separate input streams for several 
processing areas, as in serial processing or basic multiprogramming systems, 
each input stream serves as a scheduling queue which is external to the 
system. 

Further sophistication of the sequential approach is achieved by pre-reading 
the entire input stream and storing it on a secondary storage device such as 
a disk. By so doing, jobs may be executed in an order other than input 
stream sequence. In this type of system, scheduling parameters are intro¬ 
duced to control the execution sequence. Normally, these parameters are 
priorities, where a higher priority job is executed before a lower priority 
job. Alternatively, the parameters may be clock times, where a job is 
initiated at a selected time or is initiated to be completed by a certcin 
time. Clock-time scheduling may also be used to initiate selected real¬ 
time jobs. 

The batch scheduling philosophy of an extended multiprogramming system 
allows jobs submitted from more than one input stream to comp te for exe¬ 
cution assignment. Under this philosophy a scheduling queue on an inter¬ 
mediate storage device is mandatory, and jobs are placed on this queue 
whenever they are entered from either a local or remote input terminal. 

In this type of system, an input stream symbiont is used to read the input 
stream a.id store it on the scheduling queue. The symbiont is itself scheduled 
by an external event such as an operator or user command to initiate input 
stream processing. 

2 . Algorithmic scheduling provides a priority scheduling concept where a 
number of factors may be allowed to influence the selection of the next 
program chosen for execution. This criterion should probably be speci¬ 
fied for all extended multiprogramming systems. 
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1.1.1 SCHEDULING (cont'd.) 


Reference: 


3. Time initiated scheduling is frequently found in batch and real-time processing 
systems. It is used when job initiation must occur at a certr : n time or must be 
completed by a certain time. Clock time scheduling may also be used to 
initiate selected real-time jobs. Consequently, this criterion should be 
examined for a batch and real-time processing system. The criterion is 
rarely specified for a time-sharing system. 

4. Initiating programs in response to events that produce an external signal 
to the compute, is the most straightforward of the scheduling methods. 

This criterion should normally be specified for both real-time and time¬ 
sharing systems. 

5. Program-initiated scheduling permits an executing program task to request 
that another program task be scheduled for either asynchronous or subsequent 
execution. This capability frequently occurs in a time-sharing environment 
where background batch processing is initiated by a foreground time-sharing 
program. It is also found in large multi programmed batch processing systems. 

6. Conditional scheduling permits the user to specify scheduling parameters 
which must be satisfied before the program can be initiated. These para¬ 
meters tend to be the presence or absence of certain errors in a previous 
job step as well as the status of internally and externally set switches. 

7. Many times the priority levels required to control scheduling can be 
determined from the environment. A batch environment will usually only 
have a few levels of priority to expedite urgent and/or short jobs. Time¬ 
sharing environments also generally need few priority levels. A real-time 
environment usually requires several levels of priority. These levels of 
priority are assigned to individual programs according to their execution 
requirements relative to other programs. 

If the system is to operate in a mixed environment (e.g., batch and 
real-time, etc.) then a combination of priority levels for each environ¬ 
ment will probably be required. 

8. This criterion is dependent upon the hardware configuration and can only be 
specified when the hardware configuration is known. 

9. A detailed examination of the intended or existing application programs 
must be performed to determine the desirability of this criterion. 

10. This criterion should be specified when an operational scenario is included 
within the specification. 
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OPERATING SYSTEM 


REQUIREMENTS 


REQUIREMENTS CHECKLIST 


Reference Initial Extended 
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1.1.2 RESOURCE ALLOCATI ON 


Reference : 

1. The resource allocation function is responsible for assigning resources 

to each executing job in such a way that conflicting resource assignments 
are avoided. In genera! the system resources are CPU time, core storage, 

I/O devices, information files, and commonly used routines. The allo¬ 
cation of CPU time to a program is called dispatching and is covered 
separately under Section 1.1.4. 

2. This feature is not necessary in a serial processing system since ali system 
resources are normally made available to the executing program. However 
the criteria should be considered for both multiprogramming and time¬ 
sharing environments. 

3. Routines that can be used by multiple programs may be designed to be 
loaded and executed when needed, or to be permanently core resident. 

They are rarely incorporated as a part of f he executing program during 
the binding process except in serial processing or small multiprogramming 
systems, 

4. This criterion is usually relevant fora basic multiprogramming environment 
where the user needs little control over resource assignment. It is 
primarily found in dedicated environments, such as real-time foreground/ 
batch background applications in which the resources are permanently assigned 
to a particular environment. 

5. This criterion is primarily relevant for those environments supporting input 
job streams (local and remote batch processing) and is also frequently 
found in time-sharing systems. The request for system resources occurring 
within the job stream generally means that the resources are assigned to 
the requesting element (job, job step, task) for the entire duration of the 
element's processing. With the exception of data files, these resources are 
generally not available for the use of other programs until this element termin¬ 
ates. Many systems will also not permit a program task to be scheduled until 
all static resource requests have been satisfied. The criterion should probably 
not be specified for real-time applications. 

6. This feature occurs in many real-time environments as well as in large 
multiprogramming and time- sharing systems. The feature permits a 
system element to be assigned to an executing task only for the length it 
is actually needed, rather than for the duration of the entire task. A 
program will execute until it reaches a point at which a resource is required, 
reques* the resource, and then suspend itself until the resource becomes 
available. In a large system this reduces the nt mber of I/O devices required 
and allows more effective utilization of core storage. It also invokes heavy 
overhead as well a: introducing the possibility that a job in execution will 
be delayed because a resource is not available. 

It is highly recommended for those systems where several programs may require 
access to a single on-line data base. 
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OPERATING SYSTEM 


REQUIREMENTS 

























1.1.3 PROGRAM LOADING 


Reference: 

1. The program loading function is responsible for loading a program task into ore 
storage in such a way that it can be executed under the control of the system 
supervisor. There are two basic forms of program loading and either one or both 
is found in every operating system. The first, absolute loading, can only Lad 

a program that is in complete executable (core image) form. This technique 
requires very little system overhead during the loading process, though ita,.o 
usually does require an independent supoort program element to convert the var¬ 
ious programs into the executable core mage format. 

The second form of loading, relocotaf 2 loading, combines most of the functions 
of the independent support program eieme it and the absolute loader into a sing, 2 
system element. A relocatable loader wf I assign preliminary storage addresses 
to the program, perform any address adjustments that may be required, combine 
the program with any required support subroutines, and produce a loaded execut¬ 
able program. The system overhead is considerably higher for this techniqut, 
however th® human requirements for compiling, loading, and executing a program 
are greatly simplified. 

As a result, absolute program loading is most generally found in small reiL-time 
control systems (where overhead must be minimized) and in small basic multi¬ 
programming and serial processing systems where the assigned program execution 
area is relatively static (such as a fixed background partition). Relocatable load¬ 
ers occur most frequently in extended multiprogramming systems as well as in most 
time-sharing environments. Both loading techniques frequently co-exist in large 
multi-purpose systems. 

2. Programs that may be loaded into core (using either technique) must reside in a 
defined location. Every system provides a system library which is composed of the 
operating system itself, the various program language compilers, and many of the 
most frequently used application programs. The system 'ibnary is almost always 
on-lin?. Separate user libraries are generally designed to be removed when not 
in use. User libraries a,e also frequently used in large mul f i-user environments 
such as time-sharing and remote batch processing systems. 

The loading of programs through the input stream is usually a supplement to lib¬ 
raries. This technique dates back to earlier computer systems where program decks 
were maintained apart from the computer and loaded only when needed. Most 
systems still retain the capability, but apart from remote botch processing appli- 
-cations it finds little use except in program testing. 

3. The purpose of this feature is to protect the system and user libraries against the 
addition of unproven programs. Most systems provide this protection in some 
form. Therefore, the nature of the protection, and the specification of this 
criterion, would only be important in rare circumstances. 
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1.1.4 EVENT MONITORING 


Reference : 

1. Event monitoring refers to the control the operating system maintains over execu¬ 
ting programs. The function includes: dispatching control, interrupt processing 
control, event synchronization, and program limit monitoring. 

2. Dispatching is the supervisor controlled allocation of processor tir 9 to a specific 
task. Tasks that are eligible for dispatching have already been placed in an execu¬ 
tion state by the scheduler and are not waiting for I/O activity, operator responses, 
etc. Dispatching is important only in multiprogramming and time-snaring. 

Two techniques are frequently used: time-slicing and contention. Time-slicing 
allows one program to execute for a specified length of time, interrupts it , and 
selects another program to execute for another specified time period. Consequen¬ 
tly, each program in execution is guaranteed a certain slice of time for execution. 
The contention technique, on the other hand, allows the highest priority program to 
execute until it no longer requires the CPU and then assigns the CPU to the next 
highest priority program. A low priority program is not guaranteed any execution 
time beyond that not used by higher priority programs. 

Time-slicing is normally used for time-sharing whereas contention processing is 
almost mandatory for most real-time applies. :>ns. Batch processing systems may 
use either technique, with little preference shown to one or the other. 

While frequently used for evaluation, dispatching criteria are rarely specified. 
However, if an operating system is to be specifically designed for a give : appli¬ 
cation, it may be desirable to consider the dispatching technique during initial 
criteria specification. 

3. Event synchronization is the process of delaying task execution until some specified 
event occurs or the process of triggering a task upon the occurrence of a specified 
event. The most common types of events which may delay or initiate task execu¬ 
tion are I/O completions, selected time intervals, subtosk completions, end 
unsolicited key-ins. 

4. This criterion is highly dependent upon the hardware configuration and con only 
be specified in detail when the hardware configuration is known. 

Interrupts that ore provided in response to certain error conditions within the CPU 
(e.g., illegal instruction, arithmetic overflow, pari'/error, power foilure, etc.) 
are considered internal interrupts and should not enter these calculations. 

5. This criterion is frequently jpeciFied for time-sho r: 'xj at>d batch processing in order 
to prevent misuse of system resources. The featyi generally desirable in a 
testing environment to assure that a program error does not result in voluminous 
output records, excessive CPU time, etc. Generally, limits are established for. 
CPU time, output lines /cards/or records, and main and secondary storage space 
allocation. 
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OPERATING SYSTEM 


REQUIREMENTS CHECKLIST 


Reference 


REQUIREMENTS 


Initial i Extended 


1.1.5 PROGRAM TERMINATION PROCESSING 

(a) The system must deallocate all resources at program 
termination. 

(b-e) The system must provide summaries of the following 
information: 

(b) erro r statistics, 

(c) CPU time utilization, 

(d) device utilization, 

(e) file access statistics. 

(f-i) The system must provide the following options at 
abnormal termination: 

(f) durr/s core, 

(g) dump files, 

(h) execute a specified program, 

(i) initiate recovery procedures. 

(j) The system must notify ‘he operator of abnormal 
terminations. 

(k) The system must notify remote terminal users of 
abnormal terminctions. 
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1.1.5 PROGRAM TERMINATION PROCESSING 


Reference: 

1. A program terminates normally when it has completed all of its processing 
and returns control to the s^ervisor. A program may also be abnormally 
terminated by the operating system under a number of different circum¬ 
stances. This is frequently caused by a programmed request for abnormal 
termination of the job, a system determination to abort due to lack of 
corrective actions for certain error conditions, ora console command to 
terminate issued ay the computer operator. The standard abnormal term¬ 
ination procedure is to discontinue execution of the executing task, or 
possibly of the entire job, depending upon the criticality of the task 
with respect to the job. 

2. This criterion should be specified for all processing systems that use the 
static resource allocation technique. 

3. Summary status information is highly desirable for most batch and time-sharing 
applications. CPU time utilization, device utilizat'on, and file access 
statistics can also be helpful to a facility in "tuning" the system to best 
meet operational requirements. Error statistics are an aid to hardware 
maintenance personnel. 

4. This feature frequently occurs in c. batch processing or time-sharing system 
as a means of providing program testing and debug support. 

5. The initiation of recovery procedures is highly desirable and usually 
mandatory for most real-time processing systems. 

6. This feature rarely occurs in time-sharing or large batch processing 
systems. When it does, it is normally restricted to operational programs 
rather than programs being tested. It should, however, be specified for 
a real-time processing system. 

7. This criterion should be specified for time-sharing proces- n g, remote 
batch processing and interactive real-time processing. 
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OPERATING SYSTEM 


REQUIREMENTS CHECKLIST 


1.2.1 I/O SCHEDULING 

(a) The system must provide immediate scheduling of 
I/O requests. 

(b-e) The system must permit specific device assignment 
from the following system external sources: 

(b) input stream (control statement), 

(c) the operator, 

(d) a program, 

(e) interactive user. 

(0 Specific device assignment must be the responsibility 
of the system. 

(g) The system must provide queuing of input requests. 

(h) The system must permit specification of device 
priority. 

(i) The system must permit the specification of I/O 
request priorities. 

(j) The system must attempt to route I/O to a specific 
device via ur. cslI or*.c roore if tnt primaty roole 
is busy or disabled. 

(k) The system must provide facilities for alternate 
device selection. 

(l-m) The system must provide facilities for initiating 
alternate device selection: 

(l) automatically, 

(m) by the operator. 


Reference 


REQUIREMENTS 


Initial Extended 























.2.1 I/O SCHEDULING 
Reference: 


1. This criterion should be specified for all serial processing systems. This 
method is also used quite frequently in basic mult r orogramming systems 
where dedicated real-time devices are known to be available. Any 
system supporting real-time processing where there are critical I/O 
operations should also consider this criterion. 

2. Operator assignment of devices is highly desirable in most processing 
systems to permit an override of other assignment techniques due to 
unusual workloads. 

3. Specific device assignment by the system is a dynamic method of selection 
which increases system throughput. This can be associated with multi¬ 
program processing in which the system knows the status of all devices 
and can therefore make the best decision at a given moment as to which 
device should be made available to a particular program. 

4. In certain real-time processing systems it is necessary to specify device 
priority due to the critically of device operation, e.g. telemetry data, 
teleprocessing data, etc. Within some time-sharing systems, a require¬ 
ment may also exist for some terminals to have priority over other 
terminals during system operation. 

5. This criterion should be specified for most real-time processing systems. 

6. This criterion is highly desirable for a real-time processing system; how¬ 
ever, it is highly dependent upon the hardware configuration and can 
only be specified in detail when the hardware configuration is known. 

7. Automatic initiation is most useful within a time-critical environment or 
when ♦■here is a large number of alternate devices from which to make the 
selection. 
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1.2.2 DATA TRANSFER 


Reference : 

1. Data transfer controls the movement of input or output data between 
main storage and secondary storage, or between main storage and input/ 
output devices. Prior to initiating the data transfer operation, an area 
of main storage (called a buffer) must be set aside. The buffer wiil 
either contain the output data to be transmitted or will receive the input 
data as it is being transmitted. T echniques for allocating buffer areas 
vary greatly among the various operating systems. 

2. This criterion should be specified *'or all processing systems except certain 
small real-time processing systems in which the application program must 
r >erf—m all data transfer operations. 

3. This requirement frequently occurs in teleprocessing where the input or 
output line data coding structures differ irom the internal computer data 
codes. The requirement may also occur In real-time systems which 

are required to interface with analog devices, if the system will interface 
with any non-standard peripherals this criterion should also be cons : dered. 

4. An examination of the intended applications should determine if the OS is 
to support: 

Fixed length records: Records having the same length as all other 
records in the same file. 

Variable length records: Records having a length independent of the 
length of other records in the same file. 

Undefined length records: Records having a length unspecified or unknown 
to the system. 

Character string records: An unformatted record composed of a series of 
contiguous characters. Character string processing usually applies to 
teleprocessing messages. 
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.2. DEVICE MANIPULATION 
Refe rence.- 

K Device manipulation is a control function which allows a physical I/O 
device »o be positioned without actually requiring data transfer. Device 
manipulation facilities .-wnrcff/ pc...,it volume positioning (rewinding, 
forward spacing, back-spacing, disk am positioning, etc.), printer 
spacing and forms control, and card stacker selection. These features 

should be available on every operating system for the devices associalea 
with the system. 
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OPERATING SYSTEM 


REQUIREMENTS 


REQUIREMENTS CHECKLIST I Reference 


1.2.4 REMOTE TERMINAL SUPPORT 1 

(a) The system must permit interactive communications. 

(b) The system must permit terminal to terminal communi- 2 

cations. 

(c) The system must permit terminal to operator communi- 3 

cations. 


(d) The system must permit operator control over remote 4 

terminal activity. 

(e) he system must allow slaved remote terminals. 5 


(f) The system must provide a remote batch communication 
mode. 


6 













.2.4 REMOTE TERMINAL SUPPORT 


Reference: 

1. Control over remote terminal operations is found In ail time-sharing 
systems, interactive real-time systems and batch processing systems that 
provide icmote job entry. While it may be possible to attach a remote 
terminal to practically any computer system, many operating systems are 
not designed to specifically support remote terminals and special terminal 
support routines must be designed to augment the normal supervisor 
facilities. 

2. This feature is found in some time-sharing processing systems as well as 
in a few real-time environments. It is a very desirable feature for 
applications where remote users must interact with each other. 

3. This feature should be specified for all processing systems that support 
remote terminals. 

4. This feature is sometimes used to inhibit or lock-out certain terminals 
during processing of classified or private information This feature may also 
be used to restrict the usage of certain terminals during critical ( r v*i soft) 
operations. 

5. Within ertain system applications there exists f',s need to distribute or 
acquire oata from terminals other than the prime terminal. If this is .‘he 
case, then for proper operation certain terminals must be slaved to the 
prime terminal until completion of f-xecution. 

6. This criterion should be specified for all remote batch applications. 
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,1 SYSTEM STARTUP 


Reference: 

1. System startup is performed by the computer operator to initialize the 
operating system for normal processing. In batch processing environments 
this is the norma! beginnlng-of-the-day procedure once computer power 
has been turned on. In real-time environments operating around the 
clock, startup is only performed when the system has been shut down 

for some reason. 

2. Startup on g partition by partition basis allows each partition to be 
started independently of the other partitions. When the system is divided 
into environment based partitions (batch, real time, time-sharing), then 
each area con be initiated without requiring the other areas. This 
feature is also associated with basic multiprogramming where each 
partition or group of partitions is supported by its own input stream. 

3. This criterion should be specified where startup requirements are extensive 
and consistent, 

4. This feature i; highly desirable in most , rocussing systems since it 
provides flexibility in tailoring a system to meet daily requirements. 

5. This criterion should be specified for configurable processing systems. 

6. System restarting is required when a failure that affects the total system, 
rather than a specific job, occurs. Restarting functions are oriented 

to restoring as much as possible of the system environment that was valid 
at the time of the error. In critical real-time environments, for example, 
system checkpoints are frequently taken at regular intervals. These 
checkpoints can be used to reload a previous valid version of the operating 
environment when no other immediate method of repair is possible. 

7. This technique is highly desirable in a real-time processing system in 
which the system is required to interface with unique devices which 
can not be initialized using general initializaiion techniques. For 
example, user initiation programs may be required to selectively 
imtiate teleprocessing operations. 

8. Automjti -ymbiont initiation is generally .dvisable for output symbionts 
whereas manual initiation is more desirable for input symbionts. 
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OPERATING SYSTEM 


REQUIREMENTS CHECKLIST 


Reference 


REQUIRE*, 


Initial 


1.3.2 JOB CONTROL COMMUNICATION 


(a-d) The system must provide control of user jobs from the 
following interactive sources: 


1 

2 


(a) 

(b) 

(c) 

(d) 


the batch job submitter, 
the operator, 
interactive users, 
other executing jobs. 


fc) 

(f) 

(g) 


The system must permit up to 
stream devices. 


separate input 


The system must provide for the use of cataloged 
procedures. 


The system must provide procedures for modifying 
cataloged procedures. 


(h) The system must provide for conditional execution 
logic within the input stream. 


(i) The system must provide the operator with the capability 
to redirect or abort output generated by a job initiated 
at a remote terminal. 


(j) The system must provide a job control language (JCL). 
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1.3.2 JOB CONTROL COMMUNICATION 


Reference: 

1. job control communication refers to that communication between the 
operating system supervisor and either the user or the computer operator 
relating to the initiation, running, or termination of individual fobs 
within the system. In batch processing systems, user/system communica¬ 
tion is generally non-interactive, whereas in time-sha'-'ng systems it is 
almost always interactive. Operator/system communication is predomin¬ 
antly interactive. 

2. Job submitter control occurs primarily in serial batch processing environments 
where the submitter has access to the operator console area. 

In most batch environments the operator has the capability to exercise 
some control over user jobs, e.g. resource assignment, cancellation, 
etc. In a real-time environment, the operator should have the capability 
to exercise extensive control over executing jobs. 

Most time-sharing and remote batch processing systems assign job control 
functions to interactive users. 

3. This criterion is highly dependent upon the hardware configuration and 
can only be specified in detaii.when the hardware configuration is known. 

In a basic multiprogramming system this parameter is directly related to 
the number of partitions. 

4. A cataloged procedure is a set of job control statements stored on a 
library and which may be invoked by being named on a special control 
card. This is an excellent feature where jobs a-e relatively standard or 
where the control language is complicated. 

If cataloged procedures are used, then the flexibility should be available 
to allow modification of the procedures. This would be useful in diverting 
output from one device to another due to a new system configuration. 

5. This feature is frequently found in larger batch processing systems. It 
allows non-interactive users to specify conditions for performing certain 
job steps. This feature is particularly useful in program testing and 
debugging. 

6. This criterion should be specified for most batch processing and time-sharing 
systems. 
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REQUIREMENTS 


OPERATING SYSTEM 


REQUIREMENTS CHECKLIST 


Reference Initial Extended 


1.3.3 INPUT/OUTPUT STREAM CONTROL 

(a) The system must provide input stream control by 
symbiont processing. 

(b) The system must provide output stream control by 
symbiont processing. 

(c) The system must provide for the processing of up to 

input streams. 

(d) The system must allow up to o utput streams to 
be maintained. 

(e) The system must provide automatic editing of control 
command formats. 

(f-j) The system must allow the following output stream 
elements: 

(f) diagnostic messages, 

(g) trace control listings, 

b' data, 

(i) core dumps, 

(j) file dumps. 
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1.3.3 INPUT/OUTPUT STREAM CONTROL 


Reference: 

1. The input job stream is the sequence of batch processing control statements 
and program data submitted to the operating system on an input device spec¬ 
ified for this purpose. In serial processing and basic multiprogramming systems, 
the device tends to be the system card reader, though, in fact, any input 
device can be used. In these two system types, jobs are read, processed, and 
output in the order in which they occur in the input stream. 

2. In larger systems, particularly extended multiprogramming systems, the input 
and output streams are maintained as separate files in direct access storage. 
Programs called symbionts are used to read and transfer the system control 
and data cards from input devices to the input stream files. Other symbionts 
transfer output data from output stream files to the actual output devices. 

The advantage of this technique can be best illustrated with an example. 
Consider the concurrent (either multi programmed or time-shared) execution 
of two independent application programs in a system that has a single system 
printer. If both programs require the use of the printer, only one can phys¬ 
ically be assigned the device. If the device were assigned to both programs, 
output data from both jobs would appear intermixed in the listing. However, 
if one program is assigned the device, the other must be suspended until the 
device again becomes available. On the other hand, if both programs create 
separate output stream files on a direct access device, both programs can 
execute concurrently. When each program closes its output stream file, the 
file can be transferred to the printer by an output symbiont when the pt'nter 
is available. Thus, the single system printer does not inhibit concurrent 
processing. A further benefit is that the system printer is not reserved during 
the entire execution period of either application program. Rather, it is 
reserved only for the length of time it takes to transfer the output data from 
secondary storage. 

Thus, symbiont processing enables input/cutput devices to be utilized at 
physical data transfer rates, while permitting programs to process input and 
output stream data at strorage file transfer speeds rather than at ti e lower 
peripheral device speeds. The overall effect on the system is a considerable 
increase in throughput without requiring additional peripheral devices. 

Since, in time-sharing applications, the terminal is usually dedicated to a 
particular time-sharing job, and since both the input and output stream are 
usually located at the same terminal, no significant equipment or time 
saving is afforded time-sharing programs by using symbiont processing tech¬ 
niques. On the other hand, when the terminal is used for remote batch 
processing, symbiont processing can offer both time and equipment savings, 
particularly when multiple jobs are submitted. 

3. This criterion is highly dependent upon the hardware configuration and con 
only be specified in detail when the hardware configuration is known. 

4. This criterion is highly desirable for all batch processing systems. 
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OPERATING SYSTtM 


REQUIREMENTS 






i 


REQUIREMENTS CHECKLIST 


1.3.4 RESOURCE STATUS MODIFICATION 

(a-e) The system must provide control for on-line config¬ 
uration modification of the following resour- s: 

{a) peripheral devices, 

(b) mass storage allocation, 

(c) core storage allocation, 

(d) CPU time allocation, 

(e) input job queues. 

(f) The system must permit operator control of system 
configuration through operator console. 

(g) The system must permit user control of system resource 
configuration. 

(h-l) The system must recognize the following device 
conditions: 

(h) available, 

(i) down, 

(j) assigned, 

(k) reserved, 

(l) test mode. 

(m-p) The system must permit the following types of 


resource 

modification: 

(m) 

addition. 

(n) 

deletion. 

(o) 

replacement, 

(p) 

switching. 


Reference 


initial 


Extended 


1 

2 


1 

3 

4 

5 


(q) The system must allow reconfiguration in the event 
of malfunction and maintain continuity of o t “ration. 
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1.3.4 RESOURCE STATUS MODIFICATION 


Reference: 

1. In most computer operating environments, it is desirable to alter the computer 
configuration with, ut physically terminating all system operations. For 
example, a tape drive may require cleaning, a disk file may require mainten¬ 
ance, or an off-line operation may have concluded and additional peripheral 
devices may have become available for system use. As r result, it is generally 
advisable to allow the computer operator to alter the stc. js of resources availa¬ 
ble to the system during system operation. This is frequently accomplished via 
direct operator console commands to the operating system supervisor. 

2. These criteria provide the flexibility to support changing workloads. The 
modification of peripheral device configuration is particularly advantageous 
where dynamic allocation or device substitution techniques are employed. 
Modification of mass storage allocation is desirable when this storage is used 
in support of real time or time-sharing. 

On-line modification of core storage allocation is desirable in a system that 
supports fixed partitioning so that the allocation between foreground and 
background or real time/batch/time-sharing can be altered to satisfy chang¬ 
ing requirements. This feature would not be relevant to serial processing, 
variable partitioned, or paged environments. 

In multipurpose environments, it is sometimes desirable to alter the dispatching 
algorithm due to changing priorities or unusual system loads 

In any environment in which the system supports input job queues, it is a necessity 
that some control be provided to modify these queues. This control should allow 
such functions as job deleting, postponing, replacing, etc. to be performed. 

3. This feature is not prevalent d e to the impact that user control could have on 
the total multiprogramming system operation. However, when the user does 
have dedicated resources (e.g., a remote batch terminal) then the criterion 
may be advisable. 

4. Test mode recognition should be specified if on-line diagnostics are 
supported by the system. 

5. Replacement is a manual technique while switching is normally used for 
automatic transfer to a standby on-line device, 

6. This criterion is highly desirable for a real-time processing system. 
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OPERATING SYSTEM 


REQUIREMENTS CHECKLIST 


Reference 


REQUIREMENTS 


Initial Extended 


1.3.5 SYSTEM STATUS INTERROGATION 

(a) The status of the system must be displayed continuously. 

(b-c) The status of the system must be displayed upon 
request on a: 

(b) CRT, 

(c) printer. 

(d-i) The system must provide facilities to display the 
following information: 

(d) identification of current users, 

(e) resource status, 

(f) job status (executing, waiting, 
suspended, etc.) 

(g) job ...formation (priority, title, etc.) 

(h) input job queue status, 

(i) output job queue status. 

(j-m) The system must display causes of processing delays 
to include: 

(j) peripheral non-availability, j 

(k) data non-availability, 

(l) memory non-availability, 

(m) CPU delays due to unavailability 
of resources. 

















1.3.5 SYSTEM STATUS INTERROGATION 


Reference: 

1 . The computer operator is usually given the capability of displaying the status 
of various system elements. This may range from ihe status of specific jobs to 
the status of I/O devices and main and secondary storage. Systems vary con¬ 
siderably in the capabilities provided and where some may only provide status 
information on particular items, other* will produce extensive visual displays 
showing the current status, relative usage, and accumulated error statistics 
for any system element. 

2. The display of system status continuously generally requires the use of a 
reserved CRT display device. 

3. Many of these elements are valuable in monitoring the utilization of the 
system. It should be determined by the facility which will be most useful 
in their operating environment. 

4. This feature is very important to a facility in determining where hardware or 
software changes can be applied to improve operation. 
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OPERATING SYSTEM 


REQUIREMENTS CHECKLIST 


Reference 


REQUIREMENTS 


Initial 


Extended 


1.4.1 CHECKPOINTING 

(a-d) The system must provide checkpoint initiation from 
the following external sources: 


(a) control card, 

(b) system, 

(c) operator, 

(d) interactive user. 


(e) The system must permit checkpoint initiation by the 
program itself. 

(f) The system must permit checkpoint initiation by other 
programs. 


3 

4 


(g-T) The system must provide checkpointing for ihe follow¬ 
ing program types: 

(g) process control programs, 

(h) teleprocessing programs, 

(i) interrupt handling programs, 

(j) interactive programs, 

(k) batch programs, 

(l) system supervisory programs. 


5 

6 
7 


(m-o) The system must allow checkpoint file maintenance 
on the following devices: 

(m) mass storage devices, 

(n) scratch tapes, 

(o) output data tapes. 


8 


(p) The system must allow multiple checkpoints to be 
maintained. 
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.4.1 CHECKPOINTING 


Reference: 

1. Checkpointing ir the recording of information about a program and its environ¬ 
ment on secondary storage so that at any future time the program may be re¬ 
initiated from that point. Small operating systems, particularly serial process¬ 
ing systems, checkpoint all of core while most multiprogra.nmed systems check¬ 
point only individual storage partitions. 

2. In batch processing systems, control card initiation of checkpoints sometimes 
occurs but is usually considered a poor substitute for programmed initiation- 
System initiated checkpointing is prevalent in small time-sharing systems where 
programs are continually being swapped between core and mass storage. System 
initiated checkpoints are highly desirable for real-time environments as an aid 
in recycling the system. However, while this is advantageous, it is not always 
possible and the intended real-time application should be examined to see if 
this is warranted. Operator initiated checkpoints are also provided for many 
processing systems. 

3. This feature is highly desirable for all processing systems during program check¬ 
out and is sometimes mandatory in real-time processing systems to provide a 
recycle capability. 

4. This feature frequently occurs in multiprogramming systems that support priority 
processing. A priority program requiring extra core can checkpoint ant her 
program and use its assigned core. When finished the priority program restarts 
the checkpointed program. 

5. Checkpointing can be a very important feature in a real-time environment due 
to the possible requirement for continuous support. The checkpoint provides 
the system with the capability to perform quick recovery after malfunction. 

This feature can be very advantageous in process control or interrupt handling 
but is extremely difficult to implement due to the unpredictable nature of the 
systems. In a system performing real-time monitoring, but not exercising 
control over external devices, implementation is considerably easier. 

6. A checkpoint capability for interactive pogroms can be quite useful for 
program testing and debugging. 

7. Checkpointing the supervisory programs is beneficial during early stoges of 
operating system development if the area in which the supervisor resides is 
not storage protected. 

8. The device upon which checkpoint files are maintained depends upon the 
hardware configuration. If the amount of moss storage avcilable for check¬ 
point files is restricted, t » use of scratch tapes should be considered. Mass 
storage usually only allows a few checkpoints to be maintained, while mag¬ 
netic tapes allow multiple checkpoints. Checkpoint files moy ilso be main¬ 
tained on output date tapes. This has the advantage of automatically position¬ 
ing the output tope when loading the checkpoint record for restort. 
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OPERATING SYSTEM 


REQUIREMENTS 


REQUIREMENTS CHECKLIST 


1.4.1 CHECKPOINTING (Cont'd.) 

(q-u) Checkpoint information recorded must include the 
following: 

(q) register contents, 

(r) I/O channel activity, 

(s) contents of core storage, 

(t) temporary data files, 

(u) permanent data files. 

(v-y) The system must allow checkpoint notification 
directed to the following recipients: 

(v) operator console, 

(w) interactive user terminal, 

(x) job output stream, 

(y) system log. 


Reference 


Inii 


10 


ial Extended 










.4.1 CHECKPOINTING (cont'd.) 


Reference: 

9. It is necessary that all information required to restart a program be recorded. 

This information should usually consist of register contents, I/O channel ’ctivity, 
contents of core storage, and temporary data fiies. Permanent data files are 
usually not needed for checkpoint purposes unless they ore being modified. 
Similarly, ;y*tem mass storage files are not normally included within a check¬ 
point record, temporary files in use by a program when the checkpoint occurs 
are normally required for proper program restart and should automatically be 
included as part of the checkpoint output. 

10. If an interactive user has directed a checkpoint or initiated a checkpoint, 
then he should be notified. 

When checkpoint notification is directed solely to the output stream it generally 
means that restart must be performed by a separate batch processing |ob. 
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OPERATING SYSTEM 


REQUIREMENTS CHECKLIST 


REQUIREMENTS 


Reference Initial Extended 


1.4.2 RESTARTING 

(a~e) The system must permit restarr initiation from the 
following sources: 

(a) job stream, 

(b) program, 

(c) operator console, 

(d) system, 

(e) interactive user terminal. 

(f) The system must permit restart from the last check¬ 
point taken. 

(g) The system must permit restart from any specified 
checkpoint. 

(h) The system must permit checkpoints initiated on one 
system to be restarted on another system. 

(i) The system must permit restart from the beginning 
of a job step. 

(j) The system must provide automatic replacement of 
refreshable modules, 

(k) The system must provide device repositioning. 
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1 4.2 RESTARTING 


Reference: 

J. Restarting is the process of restoring the status of a iob to some previous point in 
time. The three basic iypes of restart capabilities used within all operating 
systems are checkpoint, task, and job. A restart taken from a checkpoint re¬ 
establishes the program and its data in the operating environment as they 
existed when the checkpoint was taken and resumes execution at the restart 
address included in the checkpoint. A task restart re-initiates processing from 
the beginning of the identified task. A job restart re-initiates processing from 
the beginning of the entire job. 

2. Restart initiation from the job stream is the normal procedure in a batch 
processing system where checkpoint notification is directed to the output 
stream. 

3. Restart initiation by a program should be specified for those systems that 
support program initiated checkpointing. 

4. System initiated restart is primarily a real-time processing function to attempt 
recovery after a malfunction or error. 

5. When an interactive user has the capability to initiate checAooints he should 
also have the capability to initiate restart. 

6. This criterion should be specified for all processing systems supporting check¬ 
points. 

7. If a multiple checkpoint capability is provided, this criterion should be 
specified. 

8. This criterion is highly desirable when there is a separate computer system 
that may be used as a backup. 

9. This technique frequently occurs in a batch processing system and is a fairly 
simple operation to perform. 

10. A refreshable module is unique in that it is not modified by itself or any 

other program during execution. If there are indications that a program module 
has been damaged due to a hardware malfunction, then the system can replace 
a refreshable module with a duplicate copy without disturbing any intermediate 
data calculations. 

11. Repositioning of all sequential devices at r rt should be specified for all 
processing systems. It is not normally required for IAS devices. 
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OPERATING SYSTEM 


REQUIREMENTS CHECKLIST 


Reference 


REQUIREMENTS 


Initial Extended 


2.1.1 ERROR CORRECTION (hardware errors) 

(a-c) The number of retries of a failed operation must be: 

(a) fixed, 

(b) determined at system generation time, 

(c) determined by each user program. 

(d-h) The system must provide control linkage to user 

error routines upon detection of the following errors: 

(d) CPU errors, 

(e) I/O channel or I/O processor errors, 

(f) I/O device errors, 

(g) storage parity errors, 

(h) power failure. 

(i) The system must provide interactive correction 
procedures. 

(j) The system must provide alternate I/O routing. 

(k) The system must initiate an automatic diagnostic 
routine upon equipment malfunction. 
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2.1.1 ERROR CORRECTION (hardware errors) 


Reference: 

1. Most systems provide some form of failed operation retry. The method 
most frequently used by all processing systems is a fixed number of retries. 

2. This criterion is highly desirable for all processing systems since it pro¬ 
vides a facility the flexibility to vary retry parameters based upon exper¬ 
ience. This type of variation will usually occur due to different char¬ 
acteristics of magnetic tape or non-standard I/O devices. 

3. This method is sometimes used in small to medium sized time-sharing 
systems and also real-time systems in which the user provides an I/O 
routine for unique device manipulation. 

4. This function is highly desirable for a real-time processing system. 

5. This feature rarely occurs in any processing system except as a means of 
permitting the operator to select from available options or to perform an 
override where redundancy is available. An example of override could 
be in the case of a real-time processing system which uses triple modular- 
redundant voting circuits, one of which is continuously indicating error, 
where the operator instructs the system to disregard the error since two 
circuits are still functioning. 

6. This criterion, ».Siie desirable for a real-time processing system, is highly 
dependent upon the hardware configuration. 


81 








OPERATING SYSTEM 



REQUIREMENTS CHECKLIST 

Reference 


2.1.2 ERROR NOTIFICATION (hardware errors) 


(a) 

The system must output operator console error 
messages. 

1 

(b) 

The system must output interactive user console 
error messages. 

1 

(c) 

The system must permit subroutines and tasks to 
return error codes to calling programs. 

2 

(d) 

The system must update and maintain error statistics 
files. 

3 

(©) 

The system must provide diagnostic logout of 
permanent errors. 

3,4 

(0 

The system must provide an error trace showing 
the events leading up to an error. 

3 

(g) 

The system must notify remote users of equipment 
malfunctions. 



2.1.3 ERROR RECOVERY (hardware errors) 


(a-b) 

The system must provide the following forms of 
system reconfiguration: 

1 


(a) alternate device utilization, 

(b) controlled system degradation. 


(c-d) 

The system must allow manual reconfiguration 
through: 

1 


(c) resource respecification, 

(d) system regeneration. 


(e) 

The system must permit on-line system maintenance 
of devices. 

2,3 

(0 

The system must provide for automatic restart from 
a system maintained checkpoint. 

2 


REQUIREMENTS 


Initial Extended 





















2.1.2 ERROR NOTIFICATION (hardware errors) 


Reference : 

1. This criterion is highly desirable for all processing systems. Notification 
should usually occur if an error cannot be corrected or if it is recurring 
persistently. 

2. This feature is desirable for most processing systems since continued oper¬ 
ation is usually conditional upon error notification. Other alternatives 
to this feature would be automatic task abort or, if continued operation is 
required, operator/user notification. 

3. This function is highly desirable for all processing systems but is usually 
found only in medium to large scale systems. This is a definite aid for 
hardware riaintenance and system trouble shooting. 

4. In a multiprocessor configuration, a separate processor can look at a 
logout from another processor to attempt to effect recovery. 


2.1.3 ERROR RECOVERY (hardware errors) 

Reference : 

1. This criterion is highly dependent upon the hardware configuration. 

The alternate device mode is considered the better of the two modes 
since it does not affect the capability of the system to provide total 
support. The degraded mode allows the system to support the most 
critical operations while other operations are suspended. In critical 
real-time control systems the alternate device mode is used as a first 
resort and the degraded mode is used only when no alternate devices 
are available. 

Either of these modes con be either manual or automatic, however, the 
automatic mode is used most frequently. Resource specification is the 
best method for performing manual reconfiguration while system regen¬ 
eration is generally slow and used only as a icst resort. 

2. This feature is highly desirable for a real-time processing system. 

3. This function can help reduce system down-time for scheduled mainten¬ 
ance. However, it usually requires a system that supports device pools 
or dynamic allocation of devices. 
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OPERATING SYSTEM 


REQUIREMENTS 


REQUIREMENTS CHECKLIST 

Reference 


2.2.1 ERROR CORRECTION (program errors) 


(a-g) 

The system must provide controlled linkage to user 
error routines upon detection of the following errors: 

1 

. 


(a) arithmetic errors, 

(b-d) instruction errors: 



(b) invalid instruction, 

(c) unsupported instruction, 

(d) privileged instruction. 

2 


(e) invalid address errors, 

(f) storage protection errors, 

(g) invalid data errors. 


(M 

The system must permit the inclusion of user defined 
instruction modules for unsupported instructions. 

2 

(i) 

The system mu" provide interactive correction 
procedures. 

3 


2.2.2 ERROR NOTIFICATION (program errors) 


(a) 

The iystem must output program error messages on the 
operator's console. 

1 

(b) 

The system must provide abnormal termination 
indicators. 

2 

(c) 

The system must permit job steps to set error indicators 
for subsequent job steps. 

3 

(d) 

The system must provide program error notification 
to interactive users. 

4 
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2.2.1 ERROR CORRECTION (program errors) 


References: 

1. Most frequently linkage is provided to user errrr routines due to arith¬ 
metic or invalid data errors, while other errors tend to be handled by 
the system itself. 

2. This criterion also provides the user with the capability to define and 
develop his own unique instructions. 

3. This function frequently occurs in small real-time and time-sharing 
processing systems in which the programmer/user participates in an 
on-line mode during program debug cycles. 


.2.2 ERROR NOTIFICATION (pragrem errors) 

Ref erence : 

1. This criterion, while highly desirable for a real-time processing system, 
is not usually desirable in a time-shoring or multiprogrammed batch 
processing system. 

2. This function is highly desirable for all processing systems. 

3. This feature, while highly desirable for a botch processing system, does 
not afford any advantage in o real-time or time-shoring application. 

4. This criterion is highly desirable for time-sharing processing systems. 
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OPERATING SYSTEM 


REQUIREMENTS 


REQUIREMENTS CHECKLIST 

Reference 


2.2.3 

PROGRAM TERMINATION 


(a) 

The system must provide conditional termination 
based upon a specified error level being reached. 

1 

(b-e) 

The system must allow abnormal termination to be 
initiated by: 



(b) 

the system. 

2 


(c) 

the operator, 

2 


(d) 

a user program. 



(e) 

an interactive user. 

3 


2.3.1 

OPERATOR KEY-IN EDITING 


(a) 

The system must provide assumed default options. 

1 

(b-d) 

The system must provide the following forms of 
error notification: 

2 


(b) 

coded messages. 



(c) 

free format messages. 



(d) 

tutorial messages. 



















2.2.3 


PROGRAM TERMINATION 
Reference: 


1 . 

2 . 


T(m feature Is highly desirable far all processing systems as an aid during 
initial program compilation and checkout. 

Abnormal termination by the system i, frequently used when system rule, 
are violated e.g., privileged instruction, memory protect, or in a real¬ 
time processing system due to the invocation of a degraded mode of 
operation. 


If the computer operator receives program error notification, he should 
also have the capability to initiate abnormal termination. 

3. This criterion should be specified for a timesharing processing system. 


2. 3. i OPERATOR KEY-IN EDITING 
Reference : 

1. This criterion should be considered for specification for all processing 
systems since it will expedite operator key-ins. 

2. While frequently employed for evaluation, these criteria are rarely 
specified. Generally, if the hardware configuration is small, then 
coded messages ore used since they do not squire much storage area. 

In larger systems, free format or tutorial messages may also be provided. 
When available, the tutorial presentation is the better of the two. 
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OPERATING SYSTEM 


REQUIREMENTS 




i 




REQUIREMENTS CHECKLIST 

Reference 

initial 

Extended 


2.3.2 

CONTROL COMMAND EDITING 




(a-c) 

The system must provide the following options upon 
detection of a control command error: 

1 


1 


(a) 

job termination. 

2 




(b) 

command rejection. 

3 




(c) 

request for clarification by the 
operator/user. 

3 




2.3.3 

REMOTE TERMINAL COMMUNICATION 
EDITING 




(a-d) 

The system must provide editing at the following 

1 




levels: 






(a) 

message format. 





(b) 

command structure. 





(c) 

data structure. 





(d) 

invalid characters. 




(e-g) 

The system must provide the following types of error 
notification: 

2 




(«) 

coded messages. 





(0 

free format messages. 





( 9 ) 

tutorial messoges. 




(h> 

The system must edit the user/terminal ID. 





2.3.4 

PROGRAM TO SYSTEM LINK 
VERIFICATION 




(a-c) 

The system must provide linkoge verification at the 

1 




following 

levels: 





(c) 

requested operation code, 





fb) 

(c) 

parameter list validation, 
calling sequence. 

----- —. 




88 


i 











2.3.2 CONTROL COMMAND EDITING 


Reference: 

1. A mixture of these criterion may be provided based upon the command type. 

2. This function frequently occurs in batch processing systems and is desirable 
for all non-interactive processing. 

3. This criterion is highly desirable for interactive processing applications. 


2.3.3 REMOTE TERMINAL COMMUNICATION EDITING 

Reference : 

1. These criteria are highly desirable for a time-sharing or remote batch 
processing system. 

The edit levels most frequently supported (in the order of frequency at 
which support occurs) are: data structure, message format, command 
structure, and invalid characters, 

2. Error notification should be specified for remote batch and time-sharing 
processing systems, with coded messages being most prevalent in small 
system,, free format messages prevalent in large remote batch systems, 
and tutorial messages in large time-sharing systems. 


2.3.4 PROGRAM TO SYSTEM LINK VERIFICATION 
Reference : 

1. These criteria should be considered for most processing systems since the degree 
to which linkage verification is performed can affect system reliability. 

When employed in evaluation, the system providing the most levels of verifi¬ 
cation should be favored. 



OPERATING SYSTEM 


REQUIREMENTS CHECKLIST 


Reference 


REQUIREMENTS 


Initial Extended 


3.1.1 REAL-TIME CLOCK SERVICE 

(a) The system must provide the current date. 

(b-d) The system must provide the time of day in the 

following formats: 

(b) hours/m inutes/seconds, 

(c) hours and decimal fraction, 

(d) internal code. 

(e) The system must provide date conversion facilities. 

(f) The system must provide time format conversion 

facilities. 

(g) The system must provide facilities for task interruption 
at a specified time. 

(h) The system must provide facilities for task suspension 
until a specified time. 


90 




















REAL-TIME CLOCK SERVICE 


Reference : 

1. This criterion should be specified for any system that either uses job 
accounting facilities or time-initiated scheduling. 

2. This criterion is highly desirable since it is usually more advantag¬ 
eous for the system to perform conversion than each user program. 

3. This feature usually occurs in multiprogramming systems. An interrupt 
at a specified time is useful to a program that is to acquire data at an 
exact time of day e.g., acquisition of deep space telemetry data, etc. 
Suspension of a program until a specified time is another way of acquiring 
data that arrives at a specified time. I i this way the program performs 
all execution up to a point at which the data is required and then is 
suspended. 


91 



OPERATING SYSTEM 


REQUIREMENTS 


|_ REQUIREMENTS CHECKLIST 

f — " - - - 

r 

3.1.2 INTERVAL TIMER SERVICE 

(a) The system must provide up to_interval timers 

(fixed or programmable). 

(b-c) The system must provide interrupt service as follows: 



(b) 

at the completion of a specified 
single interval. 


(c) 

at each completion of a specified 
periodic interval. 

(d-f) 

The system must permit time intervals to be 
measured in terms of: 


(d) 

actual elapsed time. 


(e) 

elapsed task execution time. 


(0 

time the task is actually using the 
CPU. 

(g) 

The system must permit task suspension for a 


specified ti 

me interval. 

(h-m) 

The timer base (update interval) must be: 


(h) 

(i) 

the same for all interval timers, 
independent for each timer, 


(i) 

fixed, 


00 

specified at system generation time 


(I) 

specified by control commands. 


(m) 

specified dynamically. 


Reference 


1 


2 


2,3 


2.3 

3.4 
3,4 


2 


5 

6 
6 
6 

7 

8 
9 


















3.1.2 INTERVAL TIMER SERVICE 


Reference : 

1. The number of interval timers a system must support is a function of how 
the interval timers will be used and the anticipated frequency of utiliza¬ 
tion. Since the interval timer is a hardware item, the number supported 
by the system is frequently established by hardware. 

2. This criterion should be specified for a real-time processing system. 

3. This function frequently occurs in a time-sharing processing system. 

4. This feature frequently occurs in systems that perform an accounting 
function. 

5. The precision of an update interval can usually be expressed in nano¬ 
seconds, microseconds, milleseconds, or seconds. A real-time pro¬ 
cessing system will usually be satisfied by microsecond or millesecond 
updates while a time-sharing processing system will usually be satisfied 
by millesecond or second updates. 

6. Having the same update interval ora fixed timer base for all interval 
timers is the simplest hardware implementation method but it may not 
be flexible enough to support a combined time sharing and real-time 
processing system. An independent update interval for each interval 
timer provides quite a bit of flexibility as long as the intervals available 
cover the realm of application possibilities. 

7. This criterion provides a great deal of flexibility if each timer update 
interval can be specified independently. 

8. This criterion provides even greater flexibility on a day to day basis. 

9. This method is the most flexible means available and should be considered 
when the interval timers are considered allocatable resources within a multi- 
programmed real-time processing system. 
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OPERATING SYSTEM 


REQUIREMENTS 


REQUIREMENTS CHECKLIST 

Reference 


3.2.1 STORAGE DUMP CONTROL 

1 

(a) 

The system must provide snapshot storage dump 
facilities. 


(b) 

The system must provide postmortem storage dump 
facilities. 


(c-i) 

The system must permit specification of dump 
boundaries as follows: 



(c) all available storage areas, 

(d-g) specified areas: 



(d) resident system area, 

(e) user areas, 

(f) I/O areas, 

(g) common areas. 

2 


(h-i) specified locations: 



(h) all storage between specified 
starting and ending locations, 

(i) list of locations. 


(i-o) 

The dumps must ontain the following information: 



(j) dump identification, 

(k) registers, 

(l) indicators, 

(m) file positions, 

(n) file contents, 

(o) memory contents. 


(p-q) 

The system must provide the following data formats 
for dumps: 



(p) machine code, 

(q) character code. 

3 

4 

(r-s) 

The system must provide the following dump format 
options: 

5 


(r) instruction interpretation, 

(s) numeric data conversion. 

















STORAGE DUMP CONTROL 


Reference : 

1. The features incorporated under storage dump control should be carefully 
evaluated in respect to the type and amount cf program testing that is 
anticipated. Since the checkout cycle can be significantly improved 
by the implementation of many of these techniques, an installation 
anticipating continued program development would do well to assess 
this area in detail. On the other hand, an installation with little 
involvement in program development would only require a minimum of 
these facilities. 

2. This criterion, if specified, should be restricted to use by facility OS 
maintenance personnel. 

3. This criterion should be considered for a real-time processing system. 

4. This criterion is highly desirable for both batch and time-sharing processing 
system. 

5. This feature is highly desirable for all processing systems as an aid in 
the checkout cycle since the programmer/user will not be required to 
interpret or convert manually. 
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OPERATING SYSTEM 


REQUIREMENTS CHECKLIST 


Reference 


REQUIREMENTS 


initial 


Extended 


3.2.1 STORAGE DUMP CONTROL (cont'd.) 

(t) The system must provide conditional dump display 
facilities, i.e., dump to high speed device for 
optional display. 

(u) The system must provide automatic dump initiation. 

(v) The system must provide conditional dump initiation, 
(w-y) The system must allow dump initiation from: 

tw) control statements, 

(x) operator key-in, 

(y) interactive user key-in. 
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3.2.1 STORAGE DUMP CONTROL (cont'd.) 


Reference; 

6. This criterion should be considered for specification if a multiple dump 
capability is provided since it will give the user selectivity in displaying 
only the dumps or portions of dumps that he desires. 

7. This feature frequently occurs in all processing systems at abnormal 
termination. 

8. This feature frequently occurs in processing systems that provide error 
code level's, etc. 
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OPERATING SYSTEM 


REQUIREMENTS CHECKLIST Reference 


3.2.2 TRACING CONTROL 

(a-e) The system must provide the following types of 1 


tracing: 


(a) 

data tracing. 

(b) 

instruction tracing. 

(c) 

logic tracing. 

(d) 

supervisor service request tracing. 

(e) 

subroutine call tracing. 


(f-h) The system must allow trace initiation from: 


(f) control statements, 

(g) operator key-in, 

(h) interactive key-in. 


2 

3 




















3.2.2 TRACING CONTROL 


Reference: 

1. These criteria are frequently employed in the evaluation of a tracing 
package and can only be specified if detailed information ir available 
on the types of traces that will be required. Data tracing traces only 
references to specified data locations, instruction tracing traces every 
instruction, logic tracing traces only changes in instruction sequence 
(e.g., branches), supervisor service request tracing traces only system 
service request occurrences, and subroutine call tracing traces only 
entry and exit from subroutines. 

2. This criterion should be considered for a batch processing system. 

3. This criterion should be considered for a real-time processing system. 

4. This criterion should be considered for a time-sharing processing system. 



OPERATING SYSTEM 


REQUIREMENTS CHECKLIST 


3.2.3 SYSTtM TEST MODE CONTROL 
(a-d) The system must provide I/O simulation facilities tor 

(a) ignore I/O requests, 

(b) reroute I/O requests, 

(c) log I/O requests, 

(d) simulate I/O error conditions . 

(e) The system must provide automatic storage dumps. 

(f) The system must provide automatic file dumps. 

(g) The system must allow the user to override abnormal 
abort services. 

(h) The system must allow the user to override subsequent 
job step cancellation. 

(i) The system mrat allow W the insertion cf breakpoints 
i t programs. 

(j) The system must allow the user to start or restart a 
program cr a specified address, 

(k) The system must permit memory searching/display. 

(!) The system must permit memory modificction. 

(m) The system must provide interrupt or error notification 
and allow the user to override those conditions. 

(n-p) The system must proviae for on-ltne program 

development from remote terminals to include: 

(n) statement by statement entry of 
program or job, 

(o) compilation or assembly with return 
diagnostics, 

(p) line update or modiHcation of a 
permanent or temporary program. 


Reference 


REQUIREMENTS 


Initial ! Extended 


IOl 
















3.2,3 SYSTEM TEST MODE CONTROL 


Re ference: 

1. When a system Has a test- mode that permits program or hardware testing 
while o^-llne support is also being provided, it is usually necessary for 
I/O simulation facilities to be provided to keep test programs from inter¬ 
fering with actual on-line processing. Simulation of I/O can also be a 
very important feature in performing program checkout prior to total 
system installation. 

The different types of simulation techniques are rarely specified; how¬ 
ever, they should be used as a means of evaluating a system's capability. 
The best method employed is rerouting of I/O requests, second is logging 
I/O requests, and last is ignoring I/O requests. The simulation of I/O 
error conditions is also important in that it allows diagnostic and error 
processing routines to be checked without actuaiiy introducing the hard¬ 
ware error. 

2. This criterion should be specified for ali processing systems as a means 
of supporting abnormal termination. 

3. This criterion should be specified for all processing systems that provide 
abnormal termination services, since the services may not be required 
or wanted by the user each time abnormal termination occurs, 

4. These criteria are highly desirable in all processing systems in which 
interactive testing is performed. 






OPERATING SYSTEM 


REQUIREMENTS 


REQUIREMENTS CHECKLIST 

Reference 

Initial 

Extended 


3.3.1 

MAINTAINING JOB CHARGE 
INFORMATION 




(a-g) 

The system must record end maintain the following job 
charge information: 

1 




(a) 

CPU time utilization. 





£b) 

I/O channel and device time utili¬ 
zation. 





(c) 

I/O record counts. 





(d) 

mein storage utilization. 





(e) 

secondary storage utilization. 





(0 

remote terminal utilization. 




i 

(g) 

job termination conditions. 




1 

(h) 

total elapsed time. 





0) 

date. 




(!) 

The system must provide linkage to user supplied 
account!ng routines. 

2 



(k-n) 

The system must allow job charge information to be 





placed on: 






to 

a printed log. 

3 




(0 

a card file. 

4 




(m) 

a system file. 

5 




(n) 

a user file. 

6 



(o-p) 

The system must allow job charge information to be 
displayed at a: 





(o) 

users terminal. 





(P) 

central site device 







i 
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3.3.1 MAINTAINING JOB CHARGE INFORMATION 


Reference : 

1. Many of these criteria are highly desirable for a batch or time¬ 
sharing processing system in which job charge information is required. 
This type of information is also useful in evaluating system utilization. 

2. This criterion is highly desirable for all processing systems that require 
accounting routines, since each installation usually has a need for 
separate charge calculations. 

3. This function frequently occurs in a batch processing system. 

4. This method is rarely used and should only be considered for small 
systems with insufficient IAS. 

5. This criterion should be specified if the accounting routines are system 
supplied. 

6. This criterion should be specified if the accounting routines are 
supplied by the installation. 


103 




OPERATING SYSTEM 


REQUIREMENTS CHECKLIST 


3.3.2 MAINTAINING ERROR STATISTICS 

The system must accumulate information for a hardware 
error summary. 

The system must accumulate information for a program 
error summary. 

The system must provide facilities for the analysis 
of error statistics (e.g., indication of faulty I/O 
devices, etc.). 

The system must provide lists of file access violation 
attempts. 


3.3.3 MAINTAINING SYSTEM UTILIZATION 
STATISTICS 

The system must maintain a summary by user account. 

The system must maintain a summary of file accesses. 

The system must maintain a summary of system service 
requests. 

The system must provide performance monitoring 
information. 


Reference 


REQUIREMENTS 


Initial Extended 


























3.3.2 MAINTAINING ERROR STATISTICS 


Reference: 

1. This criterion should be considered for specification for all processing 
system types as an aid to personnel performing hardware diagnostic 
maintenance. 

2. This function occurs infrequently, and then is usually restricted to 
batch processing systems as an aid in determining which programs 
are continually incurring error conditions. 

3. This criterion should be specified for all processing systems that accumu 
late a hardware error summary. 

4. This criterion is highly desirable for all processing systems that provide 
file access security controls. 


3.3.3 MAINTAINING SYSTEM UTILIZATION STATISTICS 

Reference: 

1. These criteria should be considered for specification in multi-user 
batch processing and time-sharing systems. 

2. These criteria are desirable when a general purpose system is to be 
tailored to a specific installation. The information provided should 
present sufficient details to enable the installation to modify system 
generation parameters for more efficient system operation. 



OPERATING SYSTEM 


REQUIREMENTS CHECKLIST 


3.4.1 CURRENT SYSTEM STATUS INTERROGA¬ 

TION 

(a-h) The system must maintain the following status informa¬ 
tion. 

(a) number of jobs, 

(b) number of interactive users, 

(c) list of active terminals, 

(d) main storage allocation 

(e) secondary storage allocation, 

(f) device allocation, 

(g) device status, 

(h) elapsed execution time. 


3.4.2 SYSTEM DEFINITION INTERROGATION 

(a-c) The system must maintain the following definition 
information: 

(a) hardware configuration, 

(b) ’ software configuration, 

(c) system limits (e.g., number of jobs 

allowed, etc.). 


Reference 


REQUIREMENTS 


Initial Extended 
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3.4.1 


CURRENT SYSTEM STATUS INTERROGATION 


Reference: 

1. These criteria should be considered for specification since they can 
be useful to a facility in monitoring system operation. These 
system features can also be useful during system evaluation. 


3.4.2 SYSTEM DEFINITION INTERROGATION 

Reference: 

1. This criterion is highly desirable in all processing systems in which 
adaptive programs are available e.g., a compiler that can operate 
with various configurations or an application program that can use 
various devices or reside in various core sizes. 

2. This criterion is highly desirable in any system in which performance 
monitoring is to be performed. 
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3.2.4 Fourth Level of Detail (Part I - Executive/Control Functions) 


This subsection covers the following fourth level executive/control 
functions: 

1.1.1.1 ALGORITHMIC SCHEDULING 

1.1.1.2 TIME INITIATED SCHEDULING 

1.1.1.3 EVENT INITIATED SCHEDULING 

1.1.1.4 PROGRAM INITIATED SCHEDULING 

1.1.1.5 CONDITIONAL SCHEDULING 

1.1.1.6 SCHEDULING QUEUE MAINTENANCE 

1.1.2.1 CORE STORAGE ALLOCATION 

1.1.2.2 I/O DEVICE ALLOCATION 

1.1.2.3 COMMON ROUTINE ALLOCATION 

1.1.3.1 LOADING CONTROL 

1.1.3.2 SWAPPING CONTROL 

1.1.3.3 STRUCTURE CONTROL 

1.1.4.1 DISPATCHING CONTROL 

1.1.4.2 EVENT SYNCHRONIZATION 

1.1.4.3 INTERRUPT PROCESSING CONTROL 

1.1.4.4 PROGRAM LIMIT MONITORING 

1.2.2.1 BUFFERING CONTROL 

1.2.2.2 DATA CODE TRANSLATION 

1.3.1.1 SYSTEM INITIALIZATION 

1.3.1.2 SYSTEM RESTART 

1.4.2.1 PROGRAM INITIATED RESTARTING 

1.4.2.2 SYSTEM INITIATED RESTARTING 

1.4.2.3 DEVICE REPOSITIONING 
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OPERATING SYSTEM 
REQUIREMENTS CHECKLIST 


1.1.1.1 ALGORITHMIC SCHEDULING 

(a) The scheduling algorithm must recognize job priority. 

1 (b) The scheduling algorithm must ascertain resource 
availability prior to job initiation. 

(c) The scheduling algorithm must be responsive to the 
length of time a program has remained unscheduled 
in a scheduling queue. 

(d) The scheduling algorithm must take into consideration 
estimated time requirements. 

(e) The scheduling algorithm must take into consideration 
predictions as to whether a given job will be I/O or 
CPU bound. 

(f) The system must permit operator modification of job 
priorities. 

(g) The system must permit operator modification of the 
scheduling algorithm. 


Reference 


1 


REQUIREMENTS 

Initial 

Extended 


UO 




















1.1.1.1 ALGORITHMIC SCHEDULING 


Reference: 

1. Algorithmic scheduling is a priority scheduling concept where man, variables 
influence the selection of the program chosen for execution. 

2. It is generally desirable that all the resources a program may need be made 
available prior to scheduling the program for execution. For example, if this 
were not done and a named input file was not on-line when the program was 
scheduled, the program would be unable to execute until the file was located, 
mounted, and recognized by the system. However, the program would still be 
occupying core storage which could otherwise be used. 

3. Since it is possible, because of low priority or lack of resources, for a program 
to be delayed in the scheduling queue for a long time, this variable is some¬ 
times included within the scheduling algorithm. If a program has been waiting 
over an established time limit the system can begin to reserve the resources that 
it requires as they become free in order to insure that all required resources will 
be available. 

4. A parameter denoting those programs which are either I/O or CPU bound can 
enable the scheduler to develop a better job mix to maximize system utiliza¬ 
tion and/or throughput. 
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OPERATING SYSTEM 


REQUIREMENTS CHECKLIST 


M .1.2 TIME INITIATED SCHEDULING 

(a) The system must permit a job to be scheduled at a 
specified time of day. 

(b) The system must permit a job to be scheduled after a 
specified time interval. 

(c) The system must permit a job to be scheduled period¬ 
ically at each elapsement of a specified time interval. 

(d) The system must permit specification of a time dead¬ 
line for scheduling a job. 

1.1.1.3 EVENT INITIATED SCHEDULING 

(a) The system must provide scheduling based upon different 
event priority levels. 

(b-h) The system must provide scheduling based upon the 
following types of events: 

(b) communications interrupts, 

(c) operator interrupts, 

(d) process control interrupts, 

(e) error conditions, 

(f) I/O completion, 

(g) task completion, 

(h) unsolicited key-ins. 


REQUIREMENTS 


Reference Initial Extended 
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1.1.1.2 TIME INITIATED SCHEDULING 


Refare nee: 

1. This criteron should be considered for real-time and batch processing 
applications. 

2. This criterion should be considered for real-time processing systems 
that monitor input from external devices either on a periodic or 
elapsed interval basis e.g., teleprocessing, telemetry updates, 
analog updates, etc. 


1.1.1.3 EVENT INITIATED SCHEDULING 
Reference: 

1. Multiple priority levels will most likely be required in t : me-critical 
environments. 

2. This criterion should be specified for real-time, remote batch and 
interactive processing systems. 

3. This criterion should be spec'fied for all processing systems. 
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OPERATING SYSTEM 
REQUIREMENTS CHECKLIS' 


1.1.1.4 PROGRAM INITIATED SCHEDULING 

(o-c) The system must provide for program initiated 
scheduling of: 

(a) symbionts, 

(b) subprograms/tasks, 

(c) independent programs/tasks. 

(d) The system must provide scheduling for immediate 

execution, 

(e,i The system must provide scheduling for asynchronous 
execution, 

(f) The system must provide scheduling for subsequent 
execut'on. 



REQUIREMENTS 

Initial 

— 

Extended 
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1.1.1.4 PROGRAM INITIATED SCHEDULING 


Reference: 

1. This feature is most frequently found in large multiprogrammed botch processing 
systems. 

2. This feature is frequently found in time-sharing systems where a foreground 
time-shoring program initiates a botch processing background program. 

3. The two simplest methods of program initiated scheduling are immediate 
execution and subsequent execution, in the immediate method the 
program in execution initiates a call for another program to be scheduled. 

The calling program is suspended until the called program terminates. 

When subsequent execution is specified, the called program is not 
executed until the calling program terminates. 

The most difficult but most versatile method is asynchronous execution 
whereby both the calling program and the called program execute con¬ 
currently. 
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OPERATING SYSTEM 


REQUIREMENTS CHECKLIST 


1.1.1.5 CONDITIONAL SCHEDULING 

(a-d) The system must provide scheduling which is conditional 
upon recognition of the following: 

(a) task completion/abnorma! termination, 

(b) internal switches set by prior task, 

(c) error code set by prior task, 

(d) externally set switches. 

(e) The system must provide for conditional logic specifi¬ 
cation by means of system parameters. 

(f) The system must provide for conditional logic specifi¬ 
cation by means of job control statements. 

(g) The system must permit conditional scheduling at the 
job level. 

(h) The system must permit conditional scheduling at the 
job step level. 

(?) The system must permit conditional scheduling at the 
task level. 


1.1.1.6 SCHEDULING QUEUE MAINTENANCE 

(a) The system must maintain_job input queues. 

(b) The system must permit up to_job entries in each 

input queue. 


REQUIREMENTS 


Reference i Initial I Extended 
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1.1.1.5 CONDITIONAL SCHEDULING 


Reference: 

1. While frequently employed for evaluation, these criteria are rarely specified. 
The most likely reason for specification would be when designing a special 
purpose batch processing system for a specific application. The intended 
application program capabilities and design should have been analyzed in 
sufficient detail to justify the need for this specification. 


1.1.i.6 SCHEDULING QUEUE MAINTENANCE 

Reference: 

1. These criteria are highly dependent upon the hardware configuration and can 
only be specified in detail when the hardware configuration is known. 

2. The number of job entries in each queue should be based on the anticipated 
work load and the degree of job stacking that will occur. For example, a 
remote terminal that submitted all of its batch jobs at a single time rather 
than on a random basis would require - relatively large queue. The amount 
of secondary storage that will be available for job stacking must also be taken 
into account. 
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OPERATING SYSTEM 

REQUIREMENTS CHECKLIST 

Reference 

REQUIREMENTS 

Initial 

Extended 


1.1.2.1 

CORE STORAGE ALLOCATION 




(a-d) 

Static core storage allocation will be provided at the 





following 1 

eve Is: 





(a) 

partition. 

1 




(b) 

rb. 

2 




(c) 

job step. 

2 




(d) 

task. 

2 



(e-i) 

Core storage must remain allocated until: 

3 




(e) 

explicit deallocation. 





(0 

job completion. 





(g) 

job step completion. 





(h) 

task completion. 





(i) 

abnormal termination 




(i-m) 

The system 

must provide static (fixed) core allocation 

4 




for: 






(i) 

program expansion. 





(k) 

I/O buffers. 





(i) 

common areas. 





(m) 

subtcsk execution. 




(n-q) 

The system 

must provide dynamic core allocation for: 

4 

\ 




(n) 

program expansion. 





('-) 

I/O buffers. 





(P) 

common areas. 





(q) 

subtask execution. 




(r) 

The system 

must permit common (shared) core alloca- 

5 




tion between tasks of the same job step. 




(*) 

The system must permit common core allocation bet- 

5 




ween job steps of a job. 




(0 

The system must permit common core allocation bet- 

6 




ween jobs. 
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1.1.2.1 CORE STORAGE ALLOCATION 


Reference: 

1. This method is generally used in most basic multiprogramming systems 
and in small to medium scale extended multiprogramming systems. 

It may also be f ’ind in systems which support concurrent operation of 
different environments e.g., real- time processing in a foreground 
partition and batch processing in a background partition. 

2. These methods of allocation occur in most time-sharing systems as well 
as in medium to large scale extended multiprogramming systems. 

3. If core is allocated at the partition level, this criterion is unnecessary. 

4. The previous level of criteria specification (1.1.2) will have determined 
whether a static, dynamic, or combined method of core allocation will 
be employed. In certain instances it becomes necessary for a program 

to expand above core estimates during operation due to a particular 
data test or tested option. Core for I/O buffers is required in order 
to efficiently transfer data or information between core and external 
devices without continually interfering with program execution. Core 
for common areas is used when there is more than one program depend¬ 
ent upon previously acquired data or information. Core for subtask 
execution is derived from the possible scheduling of a subtask by a task 
in execution, 

5. This criterion is highly desirable for most batch processing systems. 

6. This criteria should only be specified if it has been determined that it 
is desirable for multiple jobs to communicate'and pass data to each 
other. This solution avoids the problem of passing data via secondary 
storage files, it is most frequently used in teleprocessing applications 
where the message reader and message writer pass and receive data 
from the processing program via a core buffer rather than secondary 
storage areas. 
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OPERATING SYSTEM 


REQUIREMENTS CHECKLIST 

Reference 

1.1.2.2 I/O DEVICE ALLOCATION 


(a-b) The system must provide the following types of 
allocation: 

1 

(a) physical I/O devices, 

(b) logical I/O files 

2 

(c-f) The system must permit device specif cation at the 
following levels: 


(c) physical device reference, 

j 

3 


(d) symbolic device reference. 


(e) generic device reference (e.g., tape, 5 

disk, etc,), 

(f) access method reference (e.g., seq- 6 

uential, direct access). 

(g) The system must provide exclusive allocation of 
devices/files. 

(h) The system must provide shared allocation of devices/ 7 
files. 

(i-m) I/O devices must remain allocated until: 

(i) explicit deallocation, 8 

(j) job completion, 

(k) job step completion, 

(l) task completion, 

(m) abnormal termination. 8 
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1.1.2.2 


I/O DEVICE ALLOCATION 
Reference: 






1. It is generally advisable for a multiprogrammed system to control 
the allocation of physical I/O devices and logical I/O files. In 
this way, better device utilization may be achieved by assigning 
unused devices to any program requiring one. The system controlled 
allocation of logical I/O files is necessary if file security access 
controls are to be implemented. 

2. These are, in order, increasingly preferred methods of allocating 
I/O devices in a multiprogrammed environment. 

3. This method is frequently used in real-time and communication 
processing systems. 

4. Symbolic device references are particularly desirable when device 
substitution and reconfiguration features are also implemented. 

5. Generic device referen-.e allows the system to assign any device 
within a device group to a program for usage e.g., any tape drive, 
any disk, etc. This technique greatly increases system utilization 
because the OS can assign devices that it knows are not in use. 

6. The access method reference technique is considered one step above 
generic reference in that the program merely states the requirement 
for either a sequential or direct access device and the system does the 
rest. This method of device reference allows greater system control 
of devices and greater utilization of devices. 

7. This method is desirable in most time-sharing and extended multi¬ 
programming systems. 

8. This criterion should be specified if dynamic allocation is specified. 
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OPERATING SYSTEM 


REQUIREMENTS CHECKLIST 


Reference 


REQUIREMENTS 


Initial Extended 


1.1.2.3 COMMON ROUTINE ALLOCATION 

(a-c) The system must support the following routine/module 
types: 

(a) non-reusable, 

(b) serially reusable, 

(c) reentrant. 

(d-g) The system will allow common routines to reside in 
the following areas: 

(d) transient execution area, 

(e) permanent execution area within the 
supervisor, 

(f) problem program area, 

(g) independent partition. 
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1.1.2.3 COMMON ROUTINE ALLOCATION 


Reference: 

1. Programs or subroutines that can be used by more than one program 
are frequently designed to be loaded and executed when needed 
rather than incorporated as c part of the executing program during 
the binding process. These routines may be loaded into a specially- 
designated transient execution area, into any available area of 
core the executing program can find, or, if used frequently enough, 
made a part of the resident system. Allocation of these routines to 
requests is almost always dynamic rather than siatic. 

There are three types of subroutine organization that require differ¬ 
ent allocation procedures. Non-reusa'ole subroutines are subroutines 
that must be loaded “fresh 11 each time a request is made for the routine. 
Serially re-usable routines need not be reloaded; however, the routine, 
because of possible modification of constants or instactions, can 
only be used by one program at a time. Re-entrant routines may be 
used by any number of executing programs simultaneously. Thus, 
allocation of re-entrant routines is straightforward, whereas serially 
reusable routines must have a loch ^unlock facility which limits 
their assignment to a single program at a time. 

2. While frequently employed for evaluation, these criteria are rarely 
specified. 

3. A transient execution area is an area set aside to hold one or more 
routines that normally reside on secondaiy storage and which are 
loaded only when actually required. This technique is frequently 
employed for executive control routines with low utilization rates 
to provide more available main storage for application programs. 

The technique may, however, also be used by application programs 
to minimize their main storage requirements. 

4. This method frequently occurs in multiprogramming systems for 
common routines which have a high utilization rate. Although this 
method requires permanent core, if is offset by fewer requests for 
transient routines. 
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OPERATING SYSTEM 


REQUIREMENTS CHECKLIST 


REQUIREMENTS 


Reference initial I Extended 


1.1.3.1 LOADING CONTROL 
(a-c) The system mcst allow loading to be initiated by: 

(a) control statement reference, 

(b) explicit program reference, 

(c) implicit program reference. 

(d-f) The system must provide facilities for the compaction 
of fragmented core, to be initiated: 

(d) at termination of each task, 

(e) when dictated by priority requirements, 

(f) when directed by the operator, 

(g) periodically by the system. 

(h) The system must provide automatic overlay loading. 

(i) The system must provide directed overlay loading. 
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1.1.3.1 LOADING CONTROL 


Reference 

1. This criterion should be specified fo< a batch processing system. 

2. This method is frequently used in processing systems that support 
overlay loading. In this way the overlay segment in residence 
initiates the loading of the next overlay segment. 

3. This technique is gene;a!iy used with segmented or paged program 
structures. If an executing program tries to trans f er control to or 
access data from a non-resident segment or page, an inteiiupt is 
generated, the referenced segment or page is loaded, and the in¬ 
struction is re-issued. 

4. While frequently employed as an evaluation measure this criterion 
is rarely specified. However, if a multiprogrammed system is to 
utilize core to the maximum extent possible compaction is a require¬ 
ment and should be considered for both specification and evaluation. 

If the system supports a paged mode of memory allocation, however, 
compaction is generally unnecessary. 

Compaction at the termination of each task permits maximum utili¬ 
zation of core but increases system overhead tremendously. Com¬ 
paction dictated by priority requuements will minimize compaction 
overhead while making it more likely that a priority program can 
operate without causing the termination of other programs. Oper¬ 
ator directed compaction is better than none at all; however, it 
tends to be sporadic and may not increase core utilization to a 
significant extent. Some systems, to minimize overhead, only 
initiate core compaction periodically on a time or program termina¬ 
tion count interval. 

5. This criterion should be considered for specification if the system is 

to use overlays. In automatic overlay loading this function is entirely 
transparent to the programmer and con be likened to a virtual memory 
concept. In directed overlay loading the overlay in residence must 
initiate the loading of the next overlay and this load initiation is 
prepared externally and becomes port of the program structure. 
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OPERATING SYSTEM 

REQUIREMENTS CHECKLIST 


Reference 


REQUIREMENTS 


Initial 


Extended 


1.1.3.2 SWAPPING CONTROL 


1 


(a) The system must allow temporary program expansion 
into an addi onal area of core by rolling-out lower 
priority programs. 

(b) The system must allow programs to time share core 
storage. 


2 


3 
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1.1.3.2 SWAPPING CONTROL 


Reference : 

1. Swapping is a method of sharing main storage between several programs 
by maintaining each program and its status on secondary storage and 
loading each one into main storage for a limited time interval. 

Certain systems use paging as a swapping technique in which pre-defined 
program segments (pages) are swapped in and out of core. This is rarely 
specified unless the system hardware configuration is such that most pro¬ 
grams will require loading or swapping from IAS in which case paging 
should be considered for specification. If paging is specified then it 
should also be specified that the OS will allow multiple pages wirh 
the page size entirely dependent upon the architecture of the IAS 
device to be used. 

2. This method is frequently used in processing systems that support con¬ 
current modes of operation e.g., real-time foreground and batch 
background. 

3. This function frequently occurs in small to medium size time-sharing 
processing systems. 
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OPERATING SYSTEM 


REQUIREMENTS 


REQUIREMENTS CHECKLIST 


1.1.3.3 STRUCTURE CONTROL 

(a-d) The system must support the following typos of 
program structure: 

(a) simple, 

(b) overlay, 

(c) paged, 

(d) dynamic. 


Reference 

1 

2 

















1.1.3.3 STRUCTURE CONTROL 


Reference: 

1. These criteria are generally employed for evaluation, rather than 
specification. In some isolated circumstances, however, it may be 
necessary to specify the program structuring technique. 

2. A simple program structure consists of a single module occupying a 
fixed amount of main storage. An overlay program allows for 
repeated use of the same blocks of core storage during different 
stages of program execution. Thus, the overlay program is segmented 
and each segment is loaded as it is required. 

Paged and dynamic structures are considerably more sophisticated in 
scope and are common only in the 'arger multiprogrammed and time¬ 
sharing environments. Dynamic It Jag allows a relocatable module 
to be loaded into main storage upon a request for that module by an 
executing program. It differs from an overlay structure in that the 
area of main storage need not be prespecified, nor does the module 
necessarily replace or overlay an existing program segment. One of 
the major problems with dynamically-loaded |r ,grams is that the 
process creates unused core fragments when all dynamically-loaded 
programs do not terminate concurrently. Consequently, some systems 
relocate all active program segments to a contiguous core storage 
area prior to dynamically loading another module. Others only 
compact storage when core becomes exhausted or when certain high 
priority programs require loading. 

When storage is divided into pages the program loading function may 
consist of simply loading ail required main storage pages, or it may 
entail preparing the system for a process called paging. Paging 
requires a fast access secondary storage device (usually a magnetic 
drum) as a supplement to main storage. Both the secondary storage 
device and main storage are configured to the same fired page size. 

A program resides on both devices; the page of the program containing 
the instruction sequence currently • xecuting is in main storage, many 
of the other pages are in secondary storage. Whenever a page not in 
main storage is referenced for data or to transfer control, a page area 
is made ready in main storage — perhoos by moving an in-core page 
to secondary storage — and the required page is read in. A page map 
is maintained indicating the physical page assignments (main storage 
or secondary storage) and the actual storage address (core locations 
or track). This map is consulted to resolve addresses when accessing 
the data or instructions within the page. In many systems, this 
address resolution is accomplished through hardware circuitry; in 
others, it must be accomplished via software. 
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OPERATING SYSTEM 


REQUIREMENTS CHECKLIST 


REQUIREMENTS 


Reference Initial I Extended 


1.1.4.1 DISPATCHING CONTROL 

The dispatching algorithm must be modifiable at 
system generation time. 

The dispatching algorithm must be modifiable by the 
operator. 


The system must allow up to 
dispatch queue. 


entries in each 


1.1.2 EVENT SYNCHRONIZATION 

(a-d) The system must recognize the following events: 

(a) I/O completion, 

(b) t<me interval timeout, 

(c) program completion/abnormai termination, 

(d) unsolicited key-in. 
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1.1.4.1 DISPATCH!NG CONTROL 


Reference; 

1. The dispatching algorithm is the heart of every multiprogramming 
and time-sharing system. This algorithm controls the allocation of 
processor time to each contending task and is, with the scheduling 
algorithm, the factor determining single job throughput. Modifica¬ 
tions to the algorithm, while desirable, should only be incorporated 
after a comprehensive analysis of system performance. 

2. In basic multiprogramming the number of entries in the dispatch queue 
is equal to the number of partitions. 

in expended multiprogramming the number of entries in the dispatch 
queue is equal to the number of possible core resident jobs. 

In a time-sharing processing system the number of entries in the queue 
is equal to the number of users. 


1.1.4.2 EVENT SYNCHRONIZATION 
Reference: 

1. Event synchronization is the process of delaying task execution until 
some specified event occurs or the process of triggering a task upon 
the occurrence of a specified event. The most common types of 
events which may delay or initiate task execution are I/O comple¬ 
tions, selected timi° intervals, subtask completions, and unsolicited 
key-ins. 

Event synchronization may also be effected between several tasks of 
a job. One task may initiate any number of subordinate tasks and 
may execute concurrently with them. This main task may, at any 
time, issue wait requests whirh will suspend main task processing 
until one or more of the subordinate tasks have been completed. 
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OPERATING SYSTEM 


REQUIREMENTS CHECKLIST 


Reference 


REQUIREMENTS 


Initial Extended 


1.1.4.3 INTERRUPT PROCESSING CONTROL 

(a-d) The system must provide the following interrupt 
processing options: 

(a) priority recognition, 

(b) interrupt masking, 

(c) interrupt disarming, 

(d) stacked interrupt processing. 
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1.1.4.3 INTERRUPT PROCESSING CONTROL 


Reference- 

1. An interrupt, as the name indicates, is a break in the normal flow 
of program execution. An interrupt is usually caused by a hardware¬ 
generated signal such as an I/O event, a program error, a machine 
error, or an opera tor-initiated signal. 

In a real-time system, the interrupt levels of the various events to be 
monitored are usually specified when the system is generated; in 
general purpose systems, they are usually intrinsic to the system and 
may not be specified. Normally, processing on a given level will be 
interrupted whenever higher level interrupts occur; interrupts of a 
lower level than the processing program will be held pending. If 
several interrupis occur simultaneously, they are stacked and honored 
according to their priority. Unfortunately, in some systems inadequate 
stack lengths can cause multiple interrupt signals to be lost. 

Interrupt acknowledgement can be altered by disabling interrupts to 
prevent their recognition or by masking them to defer their recognition. 
When an unmasked interrupt occurs, the current instruction is usually 
allowed to complete execution. Then the program and the contents of 
he machine register are saved in main storage and control is trans¬ 
ferred to a program which will service the interrupt. This program 
may complete execution or in (urn may be interrupted by a s*i!l 
higher priority interrupt. When jn interrupt processing program does 
complete execution, control is re'urned to the highest pending 
interrupt processing routine or to the supervisor dispatching routine 
if no interrupts are pending. 
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OPERATING SYSTEM 


REQUIREMENTS CHECKLIST 


Reference 


REQUIREMENTS 


Initial Extended 


1,1.4.4 PROGRAM LIMIT MONiTORING 
(a-g) The system musf permit specification of limits for: 

(a) execution time, 

(b) number of input records, 

(c-e) number of output: 

(c) lines, 

(d) cards, 

(e) records, 

(f) main storage utilization, 

(g) secondary storage uii Iization. 
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1.1.4.4 PROGRAM LIMIT MONITORING 


Reference: 

1. Many systems monitor various resources during job execution to insure 
that certain specified limits are not exceeded. Limits are usually 
established for such elements as central processor time used, output 
records produced, and the amount of main and secondary storage space 
allocated. While installation maximums for each resource are normally 
established at system generation time, they can usually be overriauen 
by job control cards. Some systems automatically cause abnormal job 
termination when any of the system limits for a particular job are 
exceeded. Other systems permit the user to specify other actions to 
be exercised, such as operator or program notification, whenever the 
various limits are exceeded. 

In some smaller real-time systems, execution time limits are not 
explicitly set; however, the supervisor maintains a countdown loop 
which will time out unless it is periodically reset by the executing 
program. If the countdown loop times out, an interrupt is generated 
and program execution terminates. 
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OPERATING SYSTEM 


REQUIREMENTS CHECKLIST 


Reference Initial 


REQUIREMENTS 


Extended 


1.2.2.1 BUFFERING CONTROL 

(a) The system buffering concept must be based upon user 
specified areas. 

(b) The system must provide system buffer pools. 

(c) The system must permit user buffer pools. 

(d-f) The system must provide the following buffering 

methods: 

(d) simple buffering, 

(e) exchange buffering, 

(f) chained segment buffering. 

(g) The system must permit static program specification 
of buffer areas. 

(h) The system must allow buffer assignment via control 
statements. 

(i) The system must permit dynamic program specification 
of buffer areas. 
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1.2.2.1 BUFFERING CONTROL 


Referen ce: 

1. While frequently employed for evaluation this criterion is rarely 
, specified. 

2. Th is method is frequently used in a serial processing system or in a 
small real-time processing system in which the user performs the I/O 
operations. 

Buffering based upon user specified areas is the most easily imple¬ 
mented method; however, this does require that are-s of core be set 
aside for the duration of the program. 

3. An alternate method of approaching the buffer problem is the use 
of buffer pools. This provides an area of core that will always be 
used for buffering. There is not much difference between system 
buffer pools and user buffer pools except by using system buffer 
pools the user is relieved of pool handling problems. Some systems 
employ both user and system buffer pools. 

4. Static program specificai'nn of buffer areas means that the buffer 
areas are set aside during the entire execution of the program. 

Since the buffers are statically assigned there is no flexibility in 
altering the assignment other than a piogram change. This technique 
is generally prevalent in small scale systems. 

Control statement specification of buffer areas means that the buffer 
will ,-~>t be assigned until the control statem*nt is executed, however, 
it will smain assigned throughout program execution. This is a 
flexible neons of assigning buffers since the control statement is mod¬ 
ifiable input. This technique is generally prevalent in medium scale 
systems. 

Dynamic program specification is one of the most advanced methods 
of assigning buffer areas since the buffer areas are only assigned as 
the program requires them and can usually be released by the program 
when no longer needed. This technique is highly desirable in large 
scale systems. 
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1.2.2.2 DATA CODE TRANSLATION 


Reference: 

1. This criterion should be considered for specification for all processing 
systems that will be processing large amounts of data, since this 
method will decrease storage and transmission requirements. 

2. This criterion is highly dependent upon the types of hardware to be 
used, however, it should be considered fore processing systems. 


Ml 







OPERATING SYSTEM 


REQUIREMENTS CHECKLIST 


1.3.1.1 SYSTEM INITIALIZATION 

The system must permit- modification of partition sizes. 

The system must permit assignment/modification of 
partition priorities. 

The system must permit assignment/modification of 
time-slicing specifications. 


1.3.1.2 SYSTEM RESTART 

The system must schedule installation restart programs. 

The system must automatically restart jobs which 
were in a state of execution at the time the system 
came to a halt. 

The system must automatically reschedule queued 
jobs. 

Job queues must be restored by the system to their 
condition prior to the system halt. 

The system must provide manual reconfiguration 
procedures. 

The system must provide automatic reconfiguration 
procedures. 


Reference 


REQUIREMENTS 


Initial Extended 
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1.3.1.1 SYSTEM INITIALIZATION 


Reference: 

1. This criterion should be specified if a system is to provide fixed 
partitions since it will provide flexibility in meeting daily require¬ 
ments. 

2. Tills feature is desirable if subsequent tailoring of a time-sharing 
or multiprogramming system is anticipated. 


1.3.1.2 SYSTEM RESTART 

Reference: 

1. This feature frequently occurs in a real-time processing system in 
which unique pi -edures must be performed during restart. This 
method is also somewhat useful in supporting batch processing 
environments. 

2. This criterion is highly desirable for all processing systems though 
its implementation is somewhat costly. Usually in a real-time 
monitor system automatic restart of Jobs after a system halt is 
imperative. 

3. This function frequently occurs in extended multiprogramming systems. 
Normally information relative to job queues will not be affected by a 
system halt. 

4. This criterion is a highly desirable feature for all processing systems 
since it allows continued operation despite failing devices. 

While both manual and automatic reconfiguration are prevalent, 
automatic techniques are normally required to support real-time 
processing due to the speed in which if is performed. Manual con¬ 
figuration can be quite appropriate for batch and time-sharing 
environments. 
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OPERATING SYSTEM 


REQUIREMENTS CHECKLIST 


REQUIREMENTS 


Reference Initial Extended 


1.4.2.1 PROGRAM INITIATED RESTARTING 

The system must require operator consent before 
allowing a program initiated restart. 

The system must allow for the optional specification 
of operator consent before allowing a program 
initiated restart. 


1.4.2.2 SYSTEM INITIATED RESTARTING 

(a-c) The system must provide for restart under the 
following conditions: 

(a) device error recovery, 

(b) system error recovery, 

(c) power failure. 
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1.4.2.1 PROGRAM INITIATED RESTARTING 


Re ference : 

1. This criterion is highly desirable for real-time processing systems. 
When a real-time program experiences an error, reliability factors 
can usually determine whether operator consent is required prior to 
restart. 


1.4.2.2 SYSTEM INITIATED RESTARTING 

Reference: 

1. These criteria are highly desirable for a real-time processing system 
due to the usual requirement for continuous support. These criteria 
can also be quite beneficial for batch and time-sharing processing 
systems as a means of avoiding total system re-initialization. 

2. The capability of the OS to support this requirement is quite depend¬ 
ent upon a svstem hardwares non-destructive memory capability. 
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OPIATING SYSTEM 


REQUIREMENTS CHECKLIST 


Reference 


REQUIREMENTS 


Initial Extended 


1.4.2.3 DEVICE REPOSITIONING 

(a) The system must re-establish teleprocessing line 
connections. 

(b) The system must retransmit interrupted telecommuni¬ 
cations me'scges. 

(c) The system must reposition temporary files. 

(d) The system must reposition permanent files. 

(e-f) The system must reposition the following devices: 

(e) sequential access devices, 

(f) direct access devices. 






















1.4.2.3 DEVICE REPOSITIONING 


Referenc e: 

1. This criterion is highly desirable for systems supporting teleprocessing. 
Usually it is better to have the system perform this function than the 
operator since the connection can be derived from a predefined proc¬ 
edural matrix and can be performed much faster and accurately by 
the system. 

2. This criterion should be specified for all systems supporting teleprocessing 
to assure that no messages are lost due to system failure. 

3. This criterion should be considered for systems containing files on 
sequential access devices. 

4. The specification of this criterion is usually not required except in 
situations where direct access device commands do not perform an 
automatic positioning function. 
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Requirements Check list - Part il - System Mana gement Functions 

The following subsections present specification and evaluation criteria 
for -he nen-real-time components of the operating system which support and main¬ 
tain both system and application programs. 

3.3,} Fir st level of Detail (Part II - System Management F unctions) 

This subsection covers the following first level system management func¬ 
tions: 

1.0 OPERATING SYSTEM MANAGEMENT 
2.0 PROGRAM MAINTENANCE 
3.0 COMPILER INTERFACES 
4.0 MANAGEMENT SUPPORT UTILITIES 
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OPERATING SYSTEM 


REQUIREMENTS CHECKLIST 


Reference 


REQUIREMENTS 


Initial 


Extended 


1.0 OPERATING SYSTEM MANAGEMENT 

(a) System generation must be provided. 

(b) System maintenance must be provided. 


1 

2.4 

3.4 
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.0 


OPERATING SYSTEM MANAGEMENT 


Reference : 

1. Operating system management routines are provided by all systems to enable each 
installation to generate and maintain a version of the computer operating system. 

2. System generation is the process of tailoring and adapting a generalized operating 
system to the specific machine configuration and operational requirements of an 
installation. The generalized master operating system is normally provided by 
the vendor to every installation. The master system contains all the operating 
system routines required for any allowable system configuration as well as the 
vendor-developed optional routines that might be desired by a particular 
installation. 

3. System maintenance allows an installation to update the operating system in 
response to changes in the operating environment or to changes of the programs 
within the operating system itself. The latter category is generally related to 
vendor-supplied updates which are distributed periodically. Consequently, this 
type of maintenance tends to be performed fairly regularly and generally neces¬ 
sitates suspension of all other processing activity until the update is complete. 
Extensive updates to the system may involve a total regeneration of the system; 
however, minor changes may frequently be effected by simply replacing selected 
system modules. 

4. This criterion should be specified for all processing systems. 
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OPERATING SYSTEM 


REQUIREMENTS 


(a) 

(b) 

(c) 


REQUIREMENTS CHECKLIST 


2.0 PROGRAM MAINTENANCE 

The system must provide facilities for program 
library maintenance. 

The system must provide maintenance facilities for 
system control card libraries. 

The system must provide facilities for generating 
executable program modules. 


Reference 


Initial 


Extended 


1 

2 

3 

4 


i 
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2.0 


PROGRAM MAINTENANCE 


Reference : 

1. Program maintenance facilities support the maintenance and modification of appli¬ 
cation programs within the framework of the system. These facilities are distinct 
from the support features that an application program can call upon when executing; 
rather these facilities treat the application program as a product by itself. 

2. Many systems provide capabilities for maintaining one or more program types in 
indexed libraries. In general, a program libra,y is a collection of routines or 
instruction sets which are all represented at the same code level. The code levels 
generally found in contemporary operating system libraries are. macro code, 
source program code, relocatable program code, executable code, and job control 
procedures. 

3. This function is highly desirable for a batch processing system. When a great 
number of system control cards are required for the execution of a job, it is best 
for the system to catalog these control cards into a named sequence. This named 
sequence can then be referenced by one control card in the input stream rather 
than continually inserting multiple control cards in the input stream. 

4. This criterion should be specified for all processing systems. 
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OPERATING SYSTEM 


REQUIREMENTS CHECKLIST 


3.0 COMPILER INTERFACES 

(a-c) The system must provide the following executive rou¬ 
tine support for compilers: 

(a) recognition of compiler parameters on 
OS control cards, 

(b) system maintained compiler communica¬ 
tion tables, 

(c) program testing/debugging control. 

(d-f) The system must provide the following types of 
libraries in support of compilers: 

(d) source program libraries, 

(e) macro libraries, 

(f) subroutine libraries. 

vg-i) The system must provide the following system utilities 
in support of compiler language programs: 

(g) sort/merge programs, 

(h) peripheral conversion programs, 

(i) data management system programs. 


Reference 
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3.0 


COMPILER INTERFACES 


Reference : 

1. Those operating system functions that provide supporting services to the system 
language compilers are the least standard of all operating system functional 
categories. Furthermore, differences can not be directly attributed to the size, 
orientation, or sophistication of the operating system. 

2. Many operating systems grant the system compilers selected privileges which 
are not available to other non-supervisory programs. For example, several 
systems allow the compiler to use communication tables within the resident 
executive for passing parameters and storing specifications about the compila¬ 
tion. Many systems also provide special job control cards for compilers which 
include compilation parameters along with normal operating system parameters. 

In some cases the executive system may actually decode these parameters and 
place them in an appropriate compiler communication table. 

Other types of executive routine support are found in those systems that recognize 
uniquely formatted compiler input/output files and provide non-standard input and 
output symbionts for processing them. Finally, some systems also provide a series 
of compilation error codes which can be used as conditional scheduling parameters 
by subsequent tasks and steps within the job. 

3. A few systems provide and maintain unique libraries for the exclusive use of the 
system compilers. These libraries may take the form of compiler source program 
libraries, macro statement libraries, or compiler subroutine libraries. In neneral, 
the same maintenance facilities that are available for other system libraries are 
available for compiler-oriented libraries. 

4. Some compilers have the capability of generating linkage sequences to selected 
system utility programs in order that these facilities can become available to the 
compiler language programmer. For example, C080L compilers commonly allow 
references to the system sort and merge functions. Other utility functions that 
can be invoked in some systems are the data management and data handling 
support functions. 
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OPERATING SYSTEM 


REQUIREMENTS CHECKLIST 


Reference 


REQUIREMENTS 


Initial 1 Extended 


4.0 MANAGEMENT SUPPORT UTILITIES 

(a) The system must provide facilities for peripheral 
device support. 

(b) The system must provide facilities for simulation 
routi nes. 

(c) The system must provide facilities for performance 
measurement routines. 

(d) The system must provide facilities for stand-alone 
utilities. 
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4.0 


MANAGEMENT SUPPORT UTILITIES 


Reference : 

1. The muiiagement support utilities are primarily for the use of the system manager 
rather than the average user. Utility functions provided for normal users are 
listed in Part III, Data Manipulation Functions, Section 2.0. 

2. This function shouid be considered for specification for all processing systems. 

3. This function is highly desirable in a real-time processing system or a system 
that supports teleprocessing oriented programs. Certain real-time programs 
can only be invoked by the occurrence of specific interrupts. It may be 
difficult to provide the actual interrupt when these programs must be tested. 
Consequently, a capability to simulate the occurrence of the interrupts and 
to thereby invoke the program permits much greoter flexibility in program 
testing. 

Similarly, an exhaustive test of communication and line support programs might 
require a scenario so complex that it could not be performed from available 
support terminals. Again, the capability to simulate the arrival of a series of 
communication messages provides a needed testing capability. Many of these 
routines might also be used by the system manager to test and validate the 
operating system itself. 

4. Systems measurement routines enable the system manager to obtain various 
statistics about the operational use of the system. Typical statistics include 
job through-put times, file or device utilization figures, and the identification 
of bottleneck conditions. In addition, there are a few systems that provide 
visual displays of current and past system utilization reflecting error statistics 
on all configured devices, channel usage, memory allocation, programs in 
core, programs swapped out of core, and processor time consumed by each 
program at that point in time. 

5. These routines are primarily used when the system has failed and normal diagnostic 
routines are incapable of restarting the system. Two types of routines ore provided. 
The first type includes those status display routines which produce core dumps, file 
dumps, and dumps of selected diagnostic logout areas. These dumps are presented 
for interpretation by a hardware or software engineer to determine the cause of 

the failure. 

The second type consists of recovery support routines which enoble the system to 
reconstruct much of its pre-failure environment and toreinifiate processing b y 
rebuilding selected queues, reloading various program^, and restarting check- 
pointed programs. The recovery support functions are most often found in systems 
oriented to supporting real-time or communication-based processing. 
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3.3.2 Second Level of Detail (Part II - System Management Functions) 

This subsection covers the following second level system management func¬ 
tions: 

1.1 SYSTEM GENERATION 

1.2 SYSTEM MAINTENANCE 

2.1 LIBRARY AND DIRECTORY MAINTENANCE 

2.2 LOAD MODULE GENERATION 

4.1 PERIPHERAL DEVICE SUPPORT 

4.2 SYSTEM SIMULATION ROUTINES 

4.3 SYSTEM MEASUREMENT ROUTINES 

4.4 STAND-ALONE UTILITIES 
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OPERATING SYSTEM 


REQUIREMENTS CHECKLIST 


Reference 


REQUIREMENTS 


Initial Extended 


1.1 SYSTEM GENERATION 


(a-c) The system must support the following types of gener¬ 
ation: 

(a) complete system generation , 

(b) nucleus generation, 

(c) processor library generation. 

(d-e) The system must support the following metliods of 
performing system generation: 

(d) interactive macro instructions, 

(e) pre-defined control statements. 

(f-i) The system must permit specification of: 

(f) memory partitions, 

(g) available resources, 

fh) number of interrupts, 

(i) interrupt hierarchy, 

(j-k) The system must support specification of scheduling 
definition through: 

(j) priority levels, 

(k) scheduling algorithm. 

(l-p) The system must support the following system specifi¬ 
cations: 

(l) file specifications, 

(m) interrupt options, 

(n) accounting options, 

(o) error recovery procedures, 

(p) size of dynamic core allocation pool. 
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SYSTEM GENERATION 


Reference : 

1. In a medium to large scale operating system, it is generally better to perform 
nucleus generation and processor library generation as separate phases rather 
than as a single step. However, smaller systems normally combine these two 
phases into a single complete system generation package. 

2. The use of interactive as opposed to pre-defined control statements is a matter 
of personal preference. Either method is an acceptable way of perfo.ming 
system generation. The only environment where interactive techniques might 
prove more beneficial is in the "super-systems" such as CP-67 which permits 
several subordinate operating systems to time-share the computer. Since 
each user is then responsible for generating the operating system he will use, 
the interactive approach might prove handier. 

3. The greater the number of specification options, me better a general purpose 
system can be tailored to a particular installation's requirements, 

4. This criterion is highly desirable for a real-time processing system. 

5. This technique is normally used for real-time processing systems. 

6. This technique is normally used for batch processing systems. 

7. If the system is to support applications that perform file manipulation, then 
the specification at system generation of such items as file sizes, privacy 
codes, maximum file tracks, maximum file counts, etc. are important. 

8. In a facility that is supporting different environments the method of error 
recovery used may vary depending upon the environment in which the error 
occurred. 
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.1 SYSTEM GENERATION (cont'd.) 

Reference : 

9. This feature is highly desirable for most batch processing and time-sharing 
installations. 
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SYSTEM MAINTENANCE 


Referen ce 

1. This criterion is highly desirable for a real-time processing system. This feature 
al-.vws the svstem to teke the necessary steps to meet a changing hardware config¬ 
uration or to operate in a degraded or fall-back mode with little if any external 
interaction. 

2. This criterion should be specified for all processing systems. However, the instal¬ 
lation should maintain stringent control over the use of the feature and restrict its 
use to system maintenance personnel. 

3. This feature occurs in time-sharing processing systems and provides the user with 
limited system tailoring capabilities. The user can adapt certain system features 
to best meet his requirements without being detrimental to the use of the same 
features by other users. 
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OPERATING SYSTEM 


REQUIREMENTS CHECKLIST I Reference 


2.1 LIBRARY AND DIRECTORY MAINTEN- ] 

ANCE 

(a-b) The system mus provide dynamic cataloging support 
for: 

(a) load modules, 

(b) task/procedure definitions. 

(c-g) The system must provide static cataloging support 
for: 

(c) load modules, 

(d) relocatable modules, 

(e) source modules, 

(f) macro routines, 

(g) task and job procedures. 

(h-k) The system must provide the following utility 2 


functions: 

(h) 

copying libraries or library elements. 

(i) 

renaming library elements, 

(i) 

a 11 oca ti ng/dea 1 locati ng/repa ck i ng 

(k) 

library space, 

punching/listing/displaying library 


elements. 
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2.1 


LIBRARY AND DIRECTORY MAINTENANCE 


Reference : 

1. A system may provide both static and dynamic cataloging capabilities. Static 
cataloging requires the explicit execution of a library maintenance program to 
perform the cataloging function. Dynamic cataloging permits the user to add 
an element to a library without explicitly invoking a librarian program. 

2. These criteria should be considered for specification for all systems supported by 
libraries. 
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OPERATING SYSTEM 


REQUIREMENTS CHECKLIST 


REQUIREMENTS 


Reference Initial Extended 


2.2 LOAD MODULE GENERATION 

(a-b) The system must provide facilities for: 

(a) program binding, 

(b) linkage resolution. 

(c) The system must support dynamic binding. 

(d) The system must support static binding. 

(e) The system must provide binder code-altering 

facilities. 

(f-g) The system must resolve the following types of link¬ 
ages: 

(f) program control instructions, 

(g) data field references. 

(h) The system must provide an automatic system library 
scan for unrriolvtd references. 

(i) The system must provide a system library scan for 
unresolved references as a user option. 
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2.2 


LOAD MODULE GENERATION 


Referenc e: 

1. In most systems, capabilities exist to combine (bind) the object modules produced 
by various language compilers with subroutines and other object modules to pro¬ 
duce a single program. 

2. This criterion should be specified for all processing systems. 

3. In dynamic binding the system performs the binding function at the command of 
an executing task; in static binding, binding is performed as an "off-line" step 
during program development. 

4. This criterion is frequently desirable. It permits patches or altered code to be 
inserted in an object module during the binding process. While this could be 
done by reassembly or recompilation, it will be more economical to make small 
corrections at the binding stage. 

5. It is quite likely that there will be a certain amount of interaction or branching 
between different modules of a linked job. In order for the programs to operate 
properly these areas of control must be defined and resolved during load module 
generation. 

If any of the modules to be linked refer to data fields within, or created by 
other modules, or within existing library files, hen the linkage program should 
also resolve these references. 

6. During the linkage phase of program module generation, certain references may 
be made to items that are external to the system and reside in a system library. 
Unless all library elements are specifically included, some references to system 
library routines may be unresolved. Several systems provide a capability to 
scan the system library for the elements referenced. If found it is included 
within the composite load module. The library scan may be either automatic 
or a user option. 


169 





















4.1 


PERIPHERAL DEVICE SUPPORT 


Reference : 

1. This function is normally invoked when a new volume is to be added as a system 
component. The volume preparation function writes a standard system label on 
the volume, formats the records and/or tracks where track formatting is required 
(such as for disk files), creates any necessary volume directory entries, and 
allocates space for additional directories, communication buffers, etc. Only 
upon completion of this function is a volume available for normal system use. 

2. Volume maintenance functions may also provide diagnostic routines to verify 
the correctness of all volumes in the system. Normally, these routines perform 
a surface analysis of the volume to detect failing surface areas and identify 

or replace any defective areas. Certain file purging functions may also be 
invoked to erase selected areas on a volume or to clear main or secondary 
storage. 

3. This criterion is entirely dependent upon the hardware to be used by the system 
and can only be specified when the hardware is known. 


4.2 SYSTEM SIMULATION ROUTINES 
Reference : 

1. These criteria should be considered for specification for most real-time processing 
systems as well as systems that will foster large development efforts. The system 
facilities to be simulated would be such items as l/C activity, interrupt*, etc., 
while the communication facilities simulated would consist of such items os mess- 
oge transmission, receipt, etc. 
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OPERATING SYSTEM 


REQUIREMENTS CHECKLIST 


Reference 


REQUIREMENTS 


Initial Extended 


4.3 SYSTEM MEASUREMENT ROUTINES 

(a-b) The system must support the following measurement 
concepts: 

(a) sampling, 

(b) intercept. 

(c-e) The system must support the following methods of 
measurement: 

(c) software, 

(d) hardware, 

(e) mixed, 


4.4 STAND-ALONE UTILITIES 

(a-b) The system must support the following types of 
stand-alone utilities: 

(a) status displays, 

(b) recovery support. 
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4.3 SYSTEM MEASUREMENT ROUT! NES 

Reference : 

1. This function is highly desirjble for most processing systems and greatly aids an 
installation in tailoring the system to best meet operational requirements. While 
the sampling concept of measurement produces utilisation factors at periodic 
intervals, the intercept method provides a view of total utilization by recording 
all functions of interest. The intercept method provides a more comprehensive 
view of total system activity; however, it is somewhat more time consuming. 

2. Very few systems provide adequate methods of measuring system performance. 
Methods presently used consist of software statistics routines, measurement de¬ 
vices built into the system hardware, and mixtures of both methods. 


4.4 STAND-ALONE UTILITIES 
Reference : 

?. This criterion should be considered as on aid in performing diagnostic maintenance. 

2. This criterion is highly desirable for a real-time processing system and is quite 
useful for most other processing systems. 
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3.3.3 T hird Level of Detail (Part II - System Management Functions) 

This subsection covers the following third level system management func¬ 
tions: 

4.1.1 VOLUME PREPARATION 

4.1.2 VOLUME MAINTENANCE 

4.2.3 SIMULATION OF SYSTEM FACILITIES 

4.2.2 SIMULATION OF COMMUNICATION FACILITIES 

4.4.1 'TAND-ALONE STATUS DISPLAY 

4.4.2 SiAND-ALONE RECOVERY SUPPORT 
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OPERATING SYSTEM 


REQUIREMENTS 


REQUIREMENTS CHECKLIST 

Reference 


4.1.1 

VOLUME PREPARATION 


(a-e) 

The system must support the following record formats: 

1 


(a) 

blocked/unblocked, 

1 


(b) 

hardware keys, 



(c) 

software keys. 



(d) 

variable length. 



(e) 

fixed length. 


(f-g) 

The system must support the following directory 

2 


formats: 




(0 

system specified. 



(g) 

user specified. 


(h) 

The system must provide for directory levels. 


(i-k) 

The system must support the following types of 
space allocation: 



(i) 

file space. 

3 


(i) 

dynamic communication buffer areas. 

4 


(k) 

woikspace. 


(l-m) 

The system must provide the following space 
allocation modes: 

5 


(1) 

record. 



(m) 

block. 



(n) 

track. 



(o) 

cylinder, 



(p) 

segment. 



Extended 
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4.1.1 VOLUME PREPARATION 


Referen ce: 

1. Biccked/unblocked record formats are used in processing data for transmission 
between storage devices. The blocking of records is used to improve data rates 
and conserve storage space on the storage device by reducing the number of 
interrecord gaps in the file. 

Hardware and software keys are usually associated with direct access devices as 
a form of record labeling. The hardware key is usually a fixed designator that 
never changes while the software key is normally a data item within the record. 

Since the types of records handled by a system can vary due to the data or 
applications programs, the capability should be provided to support both variable 
and fixed length record formats. 

2. Directories are usually provided by a system to delineate the files, programs, etc., 
available or active within the system. The use of system specified directory formats 
is the standard method of directory organization. The support by a system of user 
created directory formats should only be considered in special development activities. 

3. If the system is to support the creation of files, then it should support the allocation 
of areas for building or creating files on storage devices. 

4. Systems that support the processing of communication information should support 
the allocation of communication buffer areas, since the system frequently may 
not be able to process this data as it occurs but must hold it for processing at a 
later time. 

5. It is usually desirable to provide several levels of space allocation. Large alloca¬ 
tion blocks are desirable for creating file and workspace areas. However, the 
system should also provide a lower level of allocation equal to the level to which 
the data element can be individually addressed. 
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4.1.2 VOLUME MAINTENANCE 


Reference : 

1. These criteria should be specified for all systems whose hardware configuration 
contains these device types. 

2. Surface analysis is a diagnostic function which determines whethe. a device 
surface area is performing properly. This type of verification should be avail¬ 
able for all recording or data holding devices. 

3. These criteria should be considered for specification for all systems with the 
automatic mode being highly desirable for a real-time processing system. 

During operation with a storage track, an error may occur which indicates 

a defective track. The automatic switch to an alternate track by the system 
allows continuous execution without external interaction. If the system does 
not provide automatic switching to an alternate track, the operator should 
be allowed to establish an alternate track and initialize the program at a 
point where the first output to the defective track was performed. 

4. This criterion should be specified for all processing systems that perform purging 
functions. Usually when a system supports the purging of storage elements, the 
purging pattern is read and checked for verification. A diagnostic check of 
storage areas is frequently a by-product of this function. 
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OPERATING SYSTEM 



REQUIREMENTS CHECKLIST 

Reference 

4.2.1 

SIMULATION OF SYSTEM 

FACILITIES 


(a-d) The system must provide simulation of the following 

1 

system facilities: 


(a) 

I/O device activity, 


(b) 

real-time interrupts. 


(c) 

error indicators. 


(d) 

executive system functions. 

2 

4.2.2 

SIMULATION OF COMMUNICATION 
FACILITIES 


(a-c) The system must provide simulation of the following 

1 

communication facilities: 


(a) 

message transmission, 


(b) 

message receipt, 


(c) 

exception processing. 



REQUIREMENTS 


Initial Extended 
















4.2.1 SIMULATION OF SYSTEM FACILITIES 


Reference : 

1. The simulation of I/O device activity and real-time interrupts is important during 
program checkout and development. Simulation of error indications is also extre- 
mly useful to debug diagnostic software routines. If the system is to support real¬ 
time processing, or checkout is to be performed during support of on-line operations, 
or if the executive system is under development, then simulation of system facilities 
should be considered. 

2. The simulation of executive system functions is highly desirable during the develop¬ 
ment of a large comprehensive operating or real-time system. By simulating these 
functions, support programs may be tested and debugged without requiring a 
completed version of the operational executive system. Thus, executive system 
development may parallel, rather than precede, support program development. 


4.2.2 SIMULATION OF COMMUNICATION FACILITIES 
Reference : 

1. These criteria should be considered for specification if the system is to support 
program development for teleprocessing or any mode of interactive communication. 
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OPERATING SYSTEM 
REQUIREMENTS CHECKLIST 


Reference 


REQUIREMENTS 


Initial Extended 


4.4/1 

STAND-ALONE STATUS DISPLAY 

(a-e) The system must provide stand-alone status displays 

of the following: 

(a) 

core storage, 

(b) 

hardware registers. 

(c) 

file storage. 

(d) 

logout areas, 

(e) 

read-only storage. 

4.4.2 

STAND ALONE RECOVERY SUPPORT 

(a-e) The system must provide the following types of 

stand-alone recovery support: 

(a) 

rebuild message queues. 

(b) 

rebuild system processing queues, 

(c) 

reconstrucr on-line file transactions, 

<d) 

re-initiate suspended processing, 

(*) 

re-establish communication line links. 

















4.4.1 STAND-ALONE STATUS DISPLAY 


Reference : 

1. The capability to obtain a stand-alone status display of each of these areas is 
highly desirable for maintenance after a system failure. 


4.4.2 STAND-ALONE RECOVERY SUPPORT 

Reference : 

1. Since stand alone routines for recovery are only invoked when all other automatic 
attempts for recovery have been exhausted, the capability presented here is a 
last-chance type of control. Consequently, the critical elements for continued 
processing should be emphasized, while the aesthetic features should be ignored. 
Thus, if the system is message based, then message queues should be rebuilt if 
there is no way to request the terminals to retransmit incompleted massages. Sim¬ 
ilarly, if communication line links are not easily restored, then a routine to 
perform this Should be provided. A word of caution, however; these are individual 
routines executed independently and as a last resort; consequently, the system will 
remain inoperational until all selected routines have been executed. If mean time 
to recovery is a critical factor, these routines should be short and few. 
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. „ Th * foll ° wi "9I ! “b«cfions present specification and evolcorion critorla 
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3.4.1 


tions: 


Fint Level of D etail (Port HI - Data Manipulation Function*) 

This subsection coven the following fint level doto manipulation func- 


1.0 DATA MANAGEMENT 
2.0 DATA HANDLING UTILITIES 
3.0 SORTING AND MERGING 
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REQUIREMENTS 


OPERATING SYSTEM 


REQUIREMENTS CHECKLIST 


1.0 DATA MANAGEMENT 

(a) The system must provide file management facilities. 

(b) The system must provide I/O support facilities. 

(c) The system must provide an independent data manage* 
ment system. 






















DMA MANAGEMENT 


Reference : 

1. The data management functions consist _>f file management facilities, I/O 
support facilities, and data management system facilities. File manage¬ 
ment facilities provide file support for the system files as entities rather 
than for the individual dura records within the files. Support for the 
latter is provided by the other two data management categories. 

I/O support facilities enable a program to access and process individual 
data records within the file. These facilities are normally invoked by- 
issuing macro instructions within the problem program and eliminate the 
need for programmers to be concerned with many of the problems of 
reading and writ'ng data records. 

Data management systems allow a user with limited programming interests 
to perform certain functions on a data file, such as retrieving and display¬ 
ing selected portions of the file. Generally, data management systems 
are adjuncts to an operating system and are more or less self-contained 
depending upon the architecture of the particular system. Consequently, 
a data management system will make use of many of the features provided 
by other operating system functions in its own internal design. 


187 



OPERATING SYSTEM 


REQUIREMENTS 

















2.0 


DATA HANDLING UTILITIES 


Referenc e: 

]. The dcfa handling utility programs are generally rather uncomplicated 
routines of general usefulness to the installation. Classically, these 
routines were independent programs which were loaded end executed 
when required. However, in contemporary systems they have been 
incorporated into the operating system and are activated by a program 
call, a system control card, or an operator key-in. These utilities 
rarely interface directly with an executing program, though they are 
frequently included as a separate job step in a multi-step job. 

2. The utility routines that produce visual output as final products are 
termed display facilities. While the printer is the most common output 
medium, CRT's, console typewriters, etc., may also be utilized by 
various display routines. 

The utility routines that provide peripheral device support perform 
such functions as volume positioning, media conversion, data editing, 
and test file support. 

These criteria should be specified for alt batch processing and time-sharing 
systems. 

3. While frequently employed for evaluation, this criterion is rarely specified. 
In general, generated code routines are somewhat more complex and faster 
in execution than interpretive code. 


189 


OPERATING SYSTEM 


REQUIREMENTS 


REQUIREMENTS CHECKLIST 

3.0 SORTING AND MERGING 

(a) The system must provide a balanced merge technique. 

(b) The system must provide an oscillating sort technique. 

(c) The system must provide a polyphase sort technique. 

(d) The system must provide a cascade sort technique. 

(e) The system must permit the use of sequential devices 
for external workspace. 

(f) The system must permit the use of random access devices 
for external workspace. 


Reference 


Initial 


Extended 


1 


2/3 

2.4 

2.5 

2.6 


7 

7 























.0 


SORTING AND MERGING 


Reference : 

1. Programs that sort or merge sets of data records normally comprise a part 
of the operating system. The sorting function takes strings of unordered 
records and sequences them according to a given key or set of keys within 
each record. The merging function, on the other hand, takes separate 
strings of records which have already been ordered by keys and produces 
a composite ordered output string. The design of most sort programs is 
such that the unordered records are placed into ordered strings and then 
merged. Consequently, a single program usually suffices to perform both 
functions. 

2. While frequently employed for evaluation, this criterion is rarely specified, 
however, it may be possible ro specify a sorting technique based on prev¬ 
ious experience or based on the hardware configuration supported by the 
system. 

3. A balanced two-way merge requires four tape units, two for output and 
two for input. In a multiway, balanced merge any number of tapes can 
be used for input as long as the same number are available for output. 

In other words, if there are "N" input tapes, then the tapes required 
for a multiway balanced merge must be "2N. 11 

4. An oscillating sort is one in which there is an oscillation between the 
internal sort (string creation) and the merge phase. Internal sort creates 
an ordered string of records on all but one of the secondary storage work 
files. The merge phase then sequences these strings from each work area 
onto the remaining work file. Control is then returned to the internal 
sort phase to create new input strings on the N-l work files. Thus 
control oscillates between string creation and string merging. 

5. Polyphase 5ort makes use of all available tape drives to perform a very 
high order of merge. The order of merge is i! N-1" where N is the number 
of tapes available. The input is distributed onto the N-1 tapes. Then 
each of these units is reod as the merged records are written on the "Nth" 
unit. Polyphase sorting is normally only advantageous for magnetic tapes 
that have a hardware "read backv/ard" capability. 

6. Like polyphase sorting, cascade sorting uses fewer tapes to do higher order 
merges. For example, with five tapes, one as input, irems are distributed 
unequally onto four drives. Aii four tapes are then merged (four-way merge) 
onto the input tape ar;a since one of the tapes has few strings it becomes empty 
first. The merge then continues as a three-woy merge* tv/o-way merge, and 
finally a copy operation. 

7. This criterion is highly dependent upon the hardware configuration and can 
only be specified when the hardware configuration is known. 
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3.4.2 Second Level of Del-ail (Part 111 - Data Manipulation Functions) 

This subsection covers the following second level data manipulation func 

tions: 

1. 1 FILE MANAGEMENT FACILITIES 

1.2 I/O SUPPORT FACILITIES 

1.3 DATA MANAGEMENT SYSTEM FACILITIES 

2.1 DISPLAY FACILITIES 

2.2 PERIPHERAL DEVICE SUPPORT 

3.1 SORT MODULE DEVELOPMENT 

3.2 SORT MODULE EXECUTION 
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OPERATING system 


REQUIREMENTS 


REQUIREMENTS CHECKLIST 


Reference Initial Extended 


1.1 FILE MANAGEMENT FACILITIES 

(a-c) The system must provide the following file management 
capabilities: 

(a) file location recognition, 

(b) file security controls, 

(c) backup and restoration facilities. 


1.2 I/O SUPPORT FACILITIES 

(a-b) The system must provide the following types of I/O 
support facilities: 

(a) physical I/O, 

(b) logical I/O. 
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FILE MANAG C MENT FACILITIES 


Reference : 

1. File management functions are invoked to locate on-line and off-line files, 
permit or restrict user access to files, and to provide backup and restoration 
services in case of file damage. 

2. This criterion should be specified for all processing systems. 

3. This criterion should be specified for all time-sharing and most batch processing 
systems supporting diverse users. 


I/O SUPPORT FACILITIES 
Reference : 

1, An important distinction is made in describing the levels of I/O support 
provided by a system. The basic level of support, physical input/output, 
is provided by routines that initiate the actual data transmission process 
and provide program access to the data in the format of transmission. 

The extended level of support, logicul input/output, allows manipulation 
of data without regard to the physical structure of the data. It thus serves 
as an intermediary between user data handling operations and the physical 
input/output services of the system. 
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OPERATING SYSTEM 


REQUIREMENTS 


REQUIREMENTS CHECKLIST 


Reference 


Initial 


Extended 


1.3 DATA MANAGEMENT SYSTEM FACILITIES | 1 

(a-d) The system must provide data management facilities I 2 

with the following capabilities: 


(a) data base creation, 

(b) data base modification, 

(c) data base ‘ iterrogation, 

(d) report development. 


(e-f) The system must provide data management facilities that 
operate in the following modes: 


3 


(e) batch, 

(f) interactive. 


'6 


















.3 DATA MANAGEMENT SYSTEM FACILITIES 


Reference : 

1. A data management system is a group of integrated routines developed to 
create and maintain an organized collection of related data, known as 
the data base, and to interrogate the data base and produce various types 
of formatted reports. A data management system will create files from 
various input sources; maintain these file* by additions, deletions, and 
alterations; create new files and reorganize and merge existing files; 
select data via user-prepared queries; r ake computations on this data; 
and produce reports in system-defT ed r user-specified formats. A data 
management system may be designed 1 operate in either a batch or inter¬ 
active mode. 

2. Normally, a data management system consists of each of these elements. 
However, there may be unusual circumstances whereby one or more of 
these elements will not be required. For example, if the installation 
intends to develop its own report generation capability, this feature need 
not be included within the DMS. 

3. This criterion is directly derived from the intended operational environrrw t. 


197 




















DISPLAY FACILITIES 


Reference : 

1. The most common display facilities provided are for main storage (core dumps), 
system catalogs, tables and directories. Other display facilities are generally 
provided for data stored on any secondary storage media supported by the system. 

2. This mode of display Is advantageous when the recipient is concerned with the 
contents of the data being displayed, rather than its machine structure. 

3. This function is very important if a picture image of the exact data structure 
is required. 

4. The printer is the most frequent means of displaying data. However, a remote 
user may only have a typewriter or CRT available. 


PERIPHERAL DEVICE SUPPORT 

Reference : 

1. This function consists of such features as rewinding, backspacing, or forward 
spacing a magnetic tape, moving a disk arm, etc. 

2. Media copying facilities should normally be available to all facility users. 

They consist of routines to accomplish such functions as tope to disk, tape to 
card, tape to tape, card to tape, etc. 

3. This is a very useful feature to a facility and should be soecified if file-oriented 
program development is to be o major insta I lotion objective. 
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OPERATING SYSTEM 


REQUIREMENTS 


REQUIREMENTS CHECKLIST 

Reference 

3.1 SORT MODULE DEVELOPMENT 


(a) The system must provide a failorable general purpose 
sort program. 

1 

(b-c) The system must provide parameter specification by: 

2 

(b) control cards, 

(c) internal linkage parameters. 


(d) The system must determine the allocation of internal 

workspace. 

3 

(e) The system must allow a supplied parameter to determine 
internal workspace allocation. 

3 

(f) The system must determine external workspace allocation 

/*> 

0 

(g) The system must allow a supplied parameter to determine 
external workspace allocation. 

3 

(h—}) The system must provide the following options: 

4 

(h) ascending/descending outpu* sequence, 

(i) single/multiple sort control fields, 

(j) single/mixed data field formats. 


(k-n) The system must recognize the following field keys. 

5 

(k) alphanumeric, 

(l) binary, 

(m) zoned 'packed cecimol, 

In' floating point. 



(c) The system must Support o user-specif ; rd collotir>g 
sequence. 


6 


















SORT MODULE DEVELOPMENT 


Reference: 

1. This technique is prevalent in most sort packages and allows the user to tailor 
the sort program eithe, .nrough control statements or selectable subroutines. 

In this way the user can create the most efficient program for his specific 
need. 

2. Many systems provide for parameter specification either through control cards 
or internal macro instructions. The use of control cards is recommended for 
"off-line" sorting of fixed data files. The use of internal macros for specify¬ 
ing parameters is most desirable when the sort program operates as an in-line 
routine for a more comprehensive application package. 

3. It is generally advisable to have the system perform all workspace calculations. 
However, there may be overriding reasons for allowing a user to specify these 
as parameters - particularly if the generated sort routine is to be a small part 
of a more comprehensive application program package. 

4. Most systems provide the capability to specifiy ascending, descending, or a 
mixture of an ascending/descending output sequence. This allows the user to 
specify different sort orders based upon different keys. 

Single sort control fields require that the sort key consist of an adjacent 
set of characters. Multiple control keys permit sorting using a number of 
data elements that need not be contiguous. 

Some systems do not provide the capability for sorting mixed files containing 
different kinds of records or merging files with fixed and variable record length. 
While other systems provide these features as options to increase user flexibility 
and to lessen the requirement for restructuring files prior to sort. 

5. it is generally advisable to have the sort program recognize every type of data 
element representation permitted within the system 

6. This function rarely occurs in standard system supplied sort programs. However, 
it is sometimes necessary for a user to produce sequences based upon an alternate 
collating sequence. For example, if the data is sorted on one system but intended 
for a different system (with a different collating sequence), it would be worthwhile 
to use the second system's collating sequence. 
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OPERATING SYSTEM 


REQUIREMENTS 


REQUIREMENTS CHECKLIST 


Reference Initial Extended 


3.2 SORT MODULE EXECUTION 

(a-c) The system must provide the following types of sorting: 

(a) full data records (record sort), 

(b) sort key and record address (tag sort), 

(c) sort key and selected fields (field select 
sort). 

(d) The system must provide control for workspace overflow. 

(e-i) The system must permit the inclusion of user codes 
relative to: 

(e) hbel processing, 

(f) input record insertion/modification/deletion, 

(g) output record insertion/modification/ 
deletion, 

(h) blocking/deblocking control, 

(i) error processing 

(j) The system must provide an automatic final pass 
sequence check. 

(k) The system must provide an optional final pass sequence 
check. 
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SORT MODULE EXECUTION 


Reference : 

1. Three types of sorting are most generally used: a record sort, where the full 
record is sorted; a field select sort, where certa'n fields are deleted from the 
record prior to sorting; and a tag sort, where the full record is stored on an 
intermediate device and only its sort key and address are sorted. The latter 
is primarily of advantage when the sort program is used as a supporting task 
of another executing application program. 

2. Exits to user codes within a sort module provides the user with the flexibility 

to perform any of the listed criteria without modifying the standard sort module. 
Each user can then perform any of the unique functions required without affecting 
the more general sort module structure. 

3. It is usually a good practice to perform a final pass sequence check to validate 
the results of the sort/merge. Whether or not this is performed automatically or 
as an option depends upon the operational philosophy of the installation. 
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3.4.3 Third Level of Detail ( Part HI - Data Manipulation Functions) 

This subsection covers the following third level data manipulation func¬ 
tions: 

1.1.1 FILE LOCATION RECOGNITION 

1.1.2 FILE ACCESS CONTROL 

1.1.3 BACKUP AND RESTORATION CAPAB'UTIES 

1.2.1 DATA ACCESS CONTROL 

1.2.2 DATA BLOCKING/DEBLOCKING CONTROL 

1.2.3 LABEL PROCESSING 

1.3.1 CONTROL SPECIFICATION 

1.3.2 DATA FILE GENERATION AND MAINTENANCE 

1.3.3 DATA QUALIFICATION AND RETRIEVAL 

1.3.4 DATA OUTPUT 

2.1.1 UNFORMATTED DISPLAY 

2.1.2 FORMATTED DISPLAY 

2.2.1 VOLUME POSITIONING 

2.2.2 MEDIA COPY FACILITIES 

2.2.3 DATA EDITING FACILITIES 

2.2.4 TEST DATA FILE SUPPORT 
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OPERATING SYSTEM 


REQUIREMENTS CHECKLIST 


Reference 


REQUiREMEN. 


Initial 


Extended 


1.1.1 FILE LOCATION RECOGNITION 

(a-b) The system must provide for locating files using the 
following methods.- 

(a) cataloged addresses, 

(b) label recognition. 

(c-d) The system musi use a file identifier which is: 

(c) system assigned, 

(d) user assigned. 

(e) The system must support multiple cataloging levels. 

(f) The system must maintain separate catalogs. 


1 

2 


4.2 

5.2 
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. 1 FILF i nr ATION RECOGNITION 


Reference: 

1. In most systems permanent data files are identified by labels assigned 
by the user or the system. File labels may be composed of such items 
as the file id -’tifier, the file edition number, the owner's name and 
account number, and perhaps a file utilization privacy code. 

2. Maintaining a catalog of file locations is the most expeuitious method 
used to locate files in that the system merely searches the catalog for 
the address of the referenced file. 

3. Both methods of label assignment are presently used. With system 
assigned labels, the system is responsible for the uniqueness of the 
labels; with user assigned labels the user must assume the res¬ 
ponsibility -r creating a unique label. Many systems provide for 
mixed label creation in which the user identifier is used by the 
system in conjunction with a system generated label. 

4. Some systems provide multiple levels of cataloging. Though not 
extensively used, this feature may be of advantage when a hierarchi¬ 
cal structure of data ba management is desired. For example, a 
payroll file could be constructed to consist of three subfiles: 
administrative staff payroll, professional slaff payroll, and oper¬ 
ational staff payroll. The professional staff payroll file could also 
be made into multiple files: managerial staff, corporation officers, 
and consultants. Thus, the number of records composing a file is 

a function of the file cataloging level, 

5. Certain systems provide for an active or master catalog and a 
temporary catalog which is used for programs that are in a checkout 
phase and which would not be placed on the master cuialog until 
operational, 
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.1.2 FILE ACCESS CONTROL 


Reference : 

1. The designation and restriction of file access may be a function under 
control of the operating system or it may merely be established by a 
set of installation programming conventions. When controlled by the 
system, the owner of a file can usually designate that the file is to be 
maintained for his use only, for the use of a designated group only, or 
for general use. Frequently, the owner may also specify the le/el of 
access afforded each designated user. For example, access may be 
restricted to a read-only level for some users while others are allowed 
full read and write capabilities. 

2. This criterion should be specified f or ail processing systems that main¬ 
tain classified or private information. 

3. Concurrent access control is required to maintain the scheduling and 
handling of concurrent or simultaneous requests for a data file from 
separate programs or users in a multiprogramming or time-sharing 
environment. Basically, the control function must determine if 
multiple user access can be permitted or whether the file must be 
restricted to single user access. In situations where multiple users 
may simultaneously access a single file, it is usually desirable to 
grant any number of them read-only access, but to restrict write 
access to a single user at a time. 

4. The level of rile access protection Is a part of the overall philosophy 
of data base design. One school of ►hought advocates a single large 
data base with individual record* and data elements individually 
allocated or denied to certcin users. Another school advocates a 
daK be ■* rcruiil’ng of multiple files with the user either allowed 

or denied access to the entire file. 

5. Either of these criteria can be specified as a method of maintaining 
access control. However, system supervisory control is considerably 
more reliable; the other method is dependent upon external users 
adhering to the conventions. System supervisory control should be 
specified for time-faring and multiple-user batch processing systems. 
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OPERATING SYSTEM 


REQUIREMENTS CHECKLIST 


Reference 


REQUIREMENTS 


Initial Extended 


1.1.3 BACKUP AND RESTORATION CAPABILITIES 
(a-b) The system must support the following backup media: 

(a) on-line devices, 

(b) off-line devices. 

(c-d) The system must provide the following restoration 
techniques: 

(c) automatic, 

(d) operator initiated. 

(e-g) The system must provide the following file backup 
techniques: 

(e) grandfather files, 

(f) periodic checkpoints, 

(g) retention of transaction data. 


2 ? 0 



















.3 BACKUP AND RESTORATION CAPABILITIES 


Reference : 

1. This function is highly dependent upon the hardware configuration and 
can only be specified when the hardware configuration is known. Syst 
support of Off-line backup devices can s : gnificantly improve the system 
recovery time and should be con»idc.ed for a real-time processing syste 

2. Thi: criterion is highly desirable for a real-time processing system. 

3. The use of grandfather files as a file backup technique provides a secur- 
base from which a system can be restored to c 'ration. However, this 
type of file backup is usually associated with a periodic update of the 
grandfather file which means that file changes made during operation ol 
the system must be retained and re-run to bring the grandfather file up 
to date. This pr .cedure is normally used for batch processing commer¬ 
cially oriented jobs. 

Periodic checkpoints are used as a backup technique in many real-time 
processing environments. However, the file maintained on the check¬ 
point will not be totally up to date and intermediate transection data 
should be retained. 

The retention of all transaction date is an excellent technique to be 
used in conjunction with redundant files or grandfather files. In this 
way the redundant file or grandfc'her file can be updated to the status 
of rhe previous working file. 
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.2.1 DATA ACCESS CONTROL 


Reference: 

1. The specification of these criteria is highly dependent upon the 
system hardware configuration, 

2. Sequential access methods process records serially and read or write 
them consecutively on a storage volume. Sequential access may be 
provided for data stored on any secondai, storage medium; although, 
certain storage media, such as magnetic tape, obviously dictate a 
file organization of this type. 

3. Random access methods read and write records without regard to the 
physical sequence in which they are stored. Consequently, records 
stored in this type of organization must have some type of identifi- 
co.ion code that will enable the record location to be determined. 
Usually, an algorithm is used to convert a unique record identifica¬ 
tion into a unique storage address on a random access storage 
device. 

4. Keyed access methods rely on a selected data field within each 
record to uniquely identify the record. This data field, called the 
record key, frequently corresponds to the record identification code, 
though it need not do so. Keyed access is useful for secondary 
storage devices which have a physical design that features hardware- 
implemented search instructions. In such systems, a record request 
will cause the read/write mechanism of the storage medium to scan 
the entire file in search of a selected record key. The technique 

is advantageous since processor time need not be spent in scanning 
secondary storage and may thus be employed with other execution 
functions. The technique is also frequently augmented by software 
which isolates a portion of the file prior to issuing the keyed search 
in order to avoid a scan of the entire file. 

5. Indexed access methods create and maintain files which, in addition 
to the data record . have directories of selected record field values 
and their corresponding record addresses. Records may then be lo¬ 
cated by sew .ing the directory rather than the file. Some form of 
immediate access storage, such as disk, is necessary for indexed access 
methods to have value. 

6. Teleprocessing data is usually composed of character strings of varying 
lengths. While not a file in the classical definition, most systems 
provide assistance In accessing and processing the relatively unform¬ 
atted messages that accumulate In the system communication buffers. 
This assistance normally handles all communication between the 
computing system and remotely located terminals. 

7. The level to which access is provided greatly increases user capability 
with a corresponding increase in system overhead. 
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OPERATING SYSTEM 


REQUIREMENTS CHECKLIST 


1.2.2 DATA BLOCKING/DEBLOCKING 
CONTROL 

(a) The system must provide record acquisition by 
deblocking. 

(b) The system must provide move mode deblocking. 

(c) The system must provide locate mode deblocking, 
(d-f) BIocking/deblocking facilities must be available for: 

(d) fixed length, 

(e) variable length, 

(f) records of undefined length. 

(g) The system must provide system specified block sizes. 

(h) The system must permit user-specified block sizes. 






















. 2.2 


DATA BLOCKING/DEBLOCKING CONTROL 
Reference: 


1. Blocking combines two or more individual records into one physical 
data block; deblocking isolates the individual records within a 
physical data block. Record lengths may be fixed, variable or 
undefined and all of these types may be blocked or unblocked. 

2. While frequently employed for evaluation these criteria are rarely 
specified. The locate mode of deblocking provides the user with the 
capability to locate and process a 'Decific record through the use of 
pointers without physically moving the record to a processing area. 

In move mode deblocking the system physically moves each deblocked 
record from the I/O buffer area info a user storage area. The locate 
modeis thus somewhat faster and requires less core storage. It may, 
however, also introduce unnecessary complexify in record processing 
for the application programmer. 

?. This function is usually supported by all processing systems that provide 
logical input/output support. 
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OPERATING SYSTEM 


REQUIREMENTS 


REQUIREMENTS CHECKLIST 


Reference 


Initial 


1.2.3 LABEL PROCESSING 

(n) The system must provide an automatic label generation 
capabi I i ty. 

(b) The system must allow users to generate labels. 

(c) The system must provide automatic label checking 
facilities. 

(d) The system must allow label checking upon user request. 


Extended 
























.2,3 LABEL PROCESSING 


Reference: 

1. Most systems provide facilities for writing and checking fiie labels 
when a data file is opened or closed. Many systems also permit the 
user to specify his own labels and to supply special routines for 
processing them. A few of the smaller systems provide no label 
generation and checking facilities, and all label processing functions 
must be performed uy the user. 

2. This function is usually provided in medium to large processing systems 
and should be specified. 

3. Many systems support user generated labels. User labels also 
require special user routines to read and validate the labels. 
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.3.1 CONTROL SPECIFICATION 


Reference: 

1. A data management system must be pn ided with a set of specifica¬ 
tions or commands delineating the jof it is to perform. The system 
interprets these specifications, and generates func.ional modules to 
perform the selected jobs. These modules may take the form of 
interpretive tables or executable programs or subroutines. Generally, 
the system will maintain an extensive library of functional subroutines 
which may be incorporated as needed into the final support modules. 
These subroutines range from arithmetic and data conversion routines 
to file searching and positioning capabilities. The generation of the 
resulting support modules is analogous to the process used by a compiler 
to convert user code into machine executable code. 

2. These formats should be specified for each of the elements selected to 
compose the data management system (see 1.3 a,b,c,d). 

3. The generative type of derivation is a process which actually structures 
a machine executable module to perform the required function. 
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OPERATING SYSTEM 


REQUIREMENTS CHECKLIST 


Reference Initial 


REQUIREMENTS 


Extended 


1.3.2 DATA FILE GENERATION AND MAINTEN¬ 
ANCE 

(a-e) The system must provide the following data file genera¬ 
tion and maintenance facilities: 

(a) fixed input transaction processing, 

(b) logical (programmed) file maintenance, 

(c) interactive file mainte..jnce, 

(d) file reorganization, 

(e) data error procedures. 

(f-g) The system must allow the following types of correction: 

(f) interactive, 

(g) pre-established. 
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DATA FILE GENERATION AND MAINTENANCE 


Reference: 

1. Data file generation and maintenance is concerned with defining 
the internal structure of a file, allocating space for the file on a 
storage device, processing input transactions against the file, per¬ 
forming logical and interactive maintenance on the file, and re¬ 
organizing the file when the structure must be modified. 

2. Fixed input transaction processing involves defining input data element 
formats, validating the data elements as they are entered, converting 
them into internal format^ and storing them in the data file. Input 
format definitions may be established prior to the entry of the data into 
the system or the data entry may be self-defining. 

3. Logical file maintenance permits conditional or programmed updating 
of a data file. Logical maintenance may or may not be transaction 
oriented. If it is, the transaction updates the object file only when 
specified criteria are satisfied. Non-transaction oriented maintenance 
is usually accomplished via internal actions generated by a computer 
pseudo-language program. For example, a logical maintenance job 
might specify the deletion of every record written after a given calendar 
date, or conversely, the retention of only those records written between 
two given calendar dates. 

4. Interactive maintenance, as its name implies, is the updating of a 
data file from an on-line terminal. Almost all interactive maintenance 
applications utilize logical file maintenance feature?. Prior to 
initiating the actual transaction the terminal user must usually establish 
logical parameters to isolate records of interest. 

5. This function provides for reorganization of one or more existing data 
files into c now composite output file. Data fields may be added, 
deleted, or changed In size or type under the restructuring p jtess. 

6. Most data management systems provide for the use of pre-es*atIished 
actions to be performed in case of on error. A more unique capability 
?s that of on-line interactive correction support whereby the interactive 
user can correct data errors as they are recognized. 
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OPERATING SYSTEM 

REQUIREMENTS CHECKLIST 

— 

Reference 

1.3.3 DATA QUALIFICATION AND RETRIEVAL 

(a-b) The system must allow the following interrogation 
modes: 

(a) interactive, 

(b) batch. 

(c-e) The system must allow retrieval mode control through 
the following pre-stored queries: 

1 

(c) fixed logic, 

2 

(d) modifiable logic. 

3 

(e) parameterized. 

(f-h) The system must allow retrieval mode control through 
the following interactive queries: 

4 

(f) cue-response format. 

5 

(g) prompting format. 

6 

(h) programmable format. 

7 

(i-m) The system must allow query processing through the 
following types of logical operators: 

8 

(i) Boolean, 

? 

(j) quantitative (occurrence), 

10 

00 arithmetic, 

11 

(1) statistical, 

12 

(m) application-defined. 

(n) The system must allow nested logical operators. 

13 

(o-r) The system must allow the following query processing 
operand formats: 

(o) constant value, 

(p) another data field, 

8 

(q) interim result, 

(r) arithmetic expressions. 

(s-u) ’’’he system must support the following types of file 
searches: 

{$) single file, 

(t) multi-file, 

(u) inter-file. 

14 


REQUIREMENTS 


Initial I Extended 




















.3.3 DATA QUALIFICATION AND RETRIEVAL 


Reference : 

1. Data management systems may be designed so that data qualification and retric 
can be accomplished in either a batch or interactive mode. In the batch rr Jr 
the data base may be interrogated by individually prepared logical queries or I 
prestored logical queries in which specific operands can be altered. In ''he in 
active mode interrogation may be by a cue-response form of query, by a promf \g 
query which "guides" the user through the interrogation, or by a user-programi d 
query. Each record satisfying the parameter of the query may be directly dispi ed, 
retained on an intermediate file for subsequent processing, cr passed on to ano r 
portion of the data management system, such as data output or file maintenanc- 
Thus, a single data qualification scheme generally serves the entire data mana< 
ment system. 

2. Fixed logic pre-stored queries allows the user to store frequently used queries c 
a library and to directly reference them at execution time. 

3. Modifiable logic pre-stored queries allow the user to temporarily alter query ic : 
prior to execution. 

4. Parameterized pre-stored queries allow the user to store skele.al queries within e 
system and then insert parameters at execution time. 

5. The cue-response format provides the user with the capability to engage in a 
question/answer dialogue with the system. The user furnishes answers to the syr ' 
questions in order to execute his request. 

6. The prompting format is one which is designed primarily for inexperienced user* 

The system prompts the user when he is uncertain of how to formulate a request. 

7. The programmable format allows the user to program and execute retrieval requt r \. 

8. The specification of each of these functions is entirely dependent upon the type 

query processing envisioned by the installation. 

9. A Boolean query allows the user to perform logical retrieval statements using th« 

comparators: equal, not equal, greater than, less than, less than or equal to, 
greater than cr equal to. Additionally, the user can combine statements by the 

logical connectors AND, OR, "nd NOT. Thus, the user can perform such fursc ns 

os: Search for "this AND this" but "NOT Hits"; search for "this OR this" but "I 'T 
this"; etc. 

10. A quantitative query allows the user to retrieve recoTfs based upon a count of tf 
unique occurrences of a specified value. 

11. An arithmetic query provides the user with the capability to perform arithmetic 
operations on data values anc to retrieve based upon the numeric result. 

12. Statistical query ollows the user to retrieve records based upon statistical colcul 
non* such as derivation from mean, median, etc. 

13. Application-defined query processing ore those queries required for special oppl 
cations. 

14. This function allows the user to construct a qualification forr.'* bated upon a 
previous computation or query. 
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REQUIREMENTS 


OPERATING SYSTEM 


REQUIREMENTS CHECKLIST 


} ,3.4 DATA OUTPUT 

i'c-c) The following me foods of report control must be 
supported by the system: 

(c) user structured, 

(b) system defined, 

(c) interactively defined, 

(d) The system must provide pre-stored report formats for 
data output, 

(e-i) The system must support the following medic: 

(e) CRT, 

(?) typev'riter, 

(g) printer, 

(h) magnetic tape drive, 

(i) card punch. 

(i) The sysrem must provide support for multiple copy 
facilities. 

(k-m) The syr’^m must provide the following types of output 
labeling: 

(k) headings, 

(0 trailers, 

(m) data labels. 

(n-o) The syjtem must provide the following data formatting 
capab : lities: 


Reference 


2 

3 


4 

5 


(n) harlzo'-’-al/vertical positioning, 

(o) rigiu/left justification. 

(p-q) The system must provide the following data altering 
capabi litis:: 

(p) data editing, 

(q) decoding. 

(r-s) The system must provide the following output account¬ 
ing capabiliiies: 

(r) counting, 

(s) totaling. 


5 

5 

6 
7 

5 


(t-u) 


The system must provide pagination control for the 
following: 

{;) printed reports, 

. lul _CRT diiglflxu-_ 


8 



















.3.4 DATA OUTPUT 


Reference: 

1. User structured reports provide the installation with the greatest flexibility 
over the report format. System defined reports, while less likely to pro¬ 
duce c format to completely satisfy every report requirement, are normally 
considerably faster. System defined reports are usually adequate for 
p-inting transaction listings and other internally oriented documents. 
Externally oriented documents (those for other than the actual DMS pro¬ 
grammer) should probably be produced via a user structured report. 

Interactively defined reports should, of course, only be considered for 
facilities supporting on-line interactive support. 

2. This criterion ?s highly desirable for a data management system that will 
process standard reports on c recurring basis. 

3. The selection of any of these criteria is dependent upon the devices 
available in the hardware configuration. 

4. This function is a highly desirable feature for a data management system 
in that it provides the user with the capability to obtain multiple copies 
without rerunning the output program. 

5. Most data management systems provide these capabilities. 

6. The capability of the system to automatically perform data editing is 
very important to a user in producing an acceptable report appearance. 
Editing consists of such things as suppressing leading zeroes, supplying 
punctuation, etc. 

7. If the DMS supports data encoding when data is entered into the fi ( e, 
then the output phase should support a corresponding decoding module. 

8. If the system is to support such devices as printers or CRTs then pagination 
control should be provided for starting a new page, numbering sequential 
pages, stopping output on one page and beginning a new page, etc. 
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OPERATING SYSTEM 
REQUIREMENTS CHECKLIST 


2.1.1 UNFORMATTED DISPLAY 

(a-d) Unformatted display must be provided by the system for 
the following media: 

(a) card, 

(b) magnetic tape, 

(c) paper *ape, 

(d) random access storage. 



I REQUIREMENTS 

Initial 

Extended 


2.1.2 FORMATTED DISPLAY 
(a-b) The system must allow format specification by: 

(a) system, 

(b) user. 

(c-d) The system must support the following specie:! display 
categories: 

(c) data files, 

(d) directories. 

(e) The system must provide for selective record display. 

(f) The system must provide for se'ective field display. 



















2.1.1 UNFORMATTED DISPLAY 


Reference : 

1. If the unformatted display option has been selected as a criterion 
(see 2.1 b), then If should be provided for each storage medium 
within the system. 


2.1.2 FORMATTED DISPLAY 

Reference : 

1. This criterion is highly desirable since it gives the user the capability 
to specify the output presentation, e.g., octal, decimal, alpha 
op-codes, etc. 

2. The capability to display data files in a formatted me e is extremely 
useful to the user during program testing and debugging. It is also 
useful to the installation as a method for displaying total file contents. 
This type of file display frequently becomes a ..jclcup to the report 
generation capabilities of a data management system. 

3. If the system maintains directories or catalogs, then the system should 
also provide routines to produce formatted displays of their contents. 

4. This criterion gives the user the capability to visually examine portions 
of a file without requiring o total file dump. This can be a definite 
aid during system troubleshooting or program testing. 
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2.2.1 VOLUME POSITIONING 

Re ference : 

1. The specification of these criteria is highly dependent upon the 
hardware configuration. 

2. These criteria should be specified for ail processing systems which 
support magnetic tape. 

3. This criterion is highly desirable for all processing systems supporting 
sequential access devices. 

4. This method frequently occurs in systems supporting direct access 
storage. 
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OPERATING SYSTEM 


REQUIREMENTS CHECKLIST 


2.2.2 MEDIA COPY FACILITIES 
(a-f) The system must provide copy facilities for the following 


media: 


(a) 

card. 

(b) 

magnetic tape, 

(c) 

paper tape. 

(d) 

random access storage, 

(e) 

main storage. 

(f) 

remote terminal devices. 


(g-j) The system must provide the following options: 

(g) field insertion, 

(h) field selection, 

(i) format conversion, 

(j) code conversion. 

(k-rn) The system must provide the following dump and reload 
facilities: 

(k) file compaction, 

(l) storage compaction, 

(m) backup file creation. 
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2.2.2 MEDIA COPY FACILITIES 


Reference : 

1. This criterion should be specified for all media supported by the 
processing system. 

2. Field insertion and field selection provides the user with the com¬ 
patibility to alter or copy selected daia fields rather than entire 
records. 

Format and code conversion is generally not too extensive in 
utility programs. It is normally only a conversion of data struc¬ 
ture rather than a conversion of the data itself. Data coae 
conversion, however, is necessary when the media use a different 
code representation e.g., punched card to paper tape. 

3. These considerations normally apply only to direct access storage 
devices. File and storage compaction is highly desirable when the 
file is fairly volatile in the number of records maintained. As 
records are deleted from a file, "holes" of unused space occur. 
Compaction eliminates these unused areas, thus decreasing the 
total amount of space required for file storage. 

4. Backup file creation is always a useful feature in case of inadvertent 
file destruction. 



OPERATING SYSTEM 


REQUIREMENTS CHECKLIST 


REQUIREMENTS 


Reference Initial Extended 


2.2.3 DATA EDITING FACILITIES 

(a-c) The following types of editing must be provided by the 
system: 

(a) full file compare, 

(b) selective field compare, 

(c) single file scan. 

(d) The system must provide for file comparison between 
differing file formats. 


2.2.4 TEST DATA FILE SUPPORT 

(a-b) The system must support the creation of the following 
types of test files: 

(a) data files, 

(b) I/O terminal message files. 

(c) The system must provide history/trace file interpretation. 
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2.2.3 DATA EDITING FACILITIES 


Reference : 

1. A full file compare is useful in validating file contents. A selective 
field compare is useful in validating selected field updates without 
validating the entire file. A single file scan is useful in checking 
file structure, sequence, and formats. 

2. This capability occurs in very few processing systms. It can, however 
be quite useful when validating related files. 


2.2.4 TEST DATA FILE SUPPORT 

Reference : 

1. Many systems provide utilities to support the checkout of application 
programs in a mode which will not impact operational files. For this 
to be done it is necessary to create a simulated environment as close 
to the operational environment as possible. By providing test data 
files and terminal message files, application program testing becomes 
considerably easier. 

2. This criterion is highly desirable for a processing system that provides 
trace capabilities (see Port I, 3.2.2). 
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3.4.4 Fourth Level of Detail (Part II! - Data Manipulation Func tions) 

This subsection covers the following fourth level data manipulation func¬ 
tions: 


1.1.2.1 FILE SECURITY CONTROL 

1.1.2.2 READ/WRITE ACCESS CONTROL 

1.1.2.3 CONCURRENT ACCESS CONTROL 

1.2.1.1 SEQUENTIAL ACCESS CONTROL 

1.2.1.2 KEYED/INDEXED ACCESS CONTROL 

1.2.1.3 TELEPROCESSING ACCESS CONTROL 

1.3.2.1 STRUCTURE DEFINITION 

1.3.2.2 SPACE ALLOCATION 

1.3.2.3 INPUT TRANSACTION PROCESSING 

1.3.2.4 LOGICAL RECORD MAINTENANCE 

1.3.2.5 INTERACTIVE FILE MAINTENANCE CONTROL 

1.3.2.6 FILE REORGANIZATION 
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OPERATING SYSTEM 


REQUIREMENTS CHECKLIST 


1.1.2.1 FILE SECURITY CONTROL 

(a-b) The system must provide the following file security 
control protection methods: 

(a) user ID, 

(b) passwords. 


1.1.2.2 READ/WRITE ACCESS CONTROL 

(o-b) The system must provide the following access restric¬ 
tions to authorized users: 

(a) read access only, 

(b) read and selective write access. 

(c) The system should provide unrestricted access to 
authorized users. 


1.1.2.3 CONCURRENT ACCESS CONTROL 

(o-c) The system must provide the following level of data 
shar’ng: 

(a) fil«, 

(b) record, 

(c) data element. 


236 











1.1.2.1 FILE SECURITY CONTROL 


Reference : 

1. If the user ID is used, then the system must maintain a checklist of the 
users that can access a particular file and perform a user ID compare 
to determine if the user can have access. If the password method is 
used, then each file has a designated password and the mere refer¬ 
ence by a user to the password allows access. Therefore, the pass¬ 
word method is more efficient from a processing standpoint, though 
potentially less secure than user ID control. 


1.1.2.2 READ/WRITE ACCESS CONTROL 
Reference : 

1. Once a user has been granted access to a file, some systems limit the 
type of operation he may perform. For example, some users may only 
read the file, other's may read the file and alter existing records, but 
may not add new records, The type of access designations that should 
be permitted must be derived from the anticipated file contents and 
the type of user* requiring access. 


1.1.2.3 CONCURRENT ACC'S CONTROL 
Reference : 

1. Concurrent access control is required to nintain the scheduling and 
handling of concurrent or simultaneous requests for a data file from 
separate programs or users in a multiprogramming or time-sharing 
environment. Basically, the control function must determine if 
multiple user access can be permitted or whether the file must be 
restricted to single user access. In situations where multiple users 
may simultaneously access a single file, it is usually desirable to 
grant any number of them read-only access but to restrict write 
access to a single user at a time. 
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1 . 2 . 1.1 


SEQUENTIAL ACCESS CONTROL 


Reference : 

1. This function is usually desirable for sequential record processing. Auto¬ 
matic read-ahead facilities are provided to decrease the amount of wait 
time a program may have to incur during successive access operations. In 
this way the program can be processing previously obtained data while 
the next data access is being performed. 


1.2.1.2 KEYED/INDEXED ACCESS CONTROL 

Reference : 

1. Automatic key computation relieves the user of determining the physical 
storage address of the record. 

2. Automatic index maintenance relieves the user of updating the index 
of an indexed file when he adds or deletes a record from the file. 

3. Indexes are provided for more efficient access of data. However, if 
the index itself becomes too large, then an index to the index may be 
desirable. For example, a disk index could consist of an index for all 
cylinders in a file and a separate track index for all tracks on a cylinder. 
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OPERATING SYSTEM 


requirement: checklist 


REQUIREMENTS 


Reference Initial Extended 


1.2.1.3 TELEPROCESSING ACCESS CONTROL 

(a) The system must provide automatic message time 
stamping. 

(b) The system must provide optional message time stamping. 

(c-e) The system must provide the following iiiput message 
processing facilities: 

(c) message routing, 

(d) message queuing, 

(e) message priority recognition. 

(f-h) The system must provide the following output message 
processing facilities: 

(f) message routing, 

(g) message queuing, 

(h) message priority recognition. 
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1.2.1.3 TELEPROCESSING ACCESS CONTROL 


Reference: 


1 . 

2 . 


3. 


This criterion is highly durable for oil systems support,ng teleprocessing. 

Me«age time-stomping Is one of the more convenient woys of ottoching 

l “o ,r f ° ' ach | m '“° 0e en,erin 8 the system. At the sometime, 

'°'°'” ri Ke sys, . em !° ««'!>'recognize messoges thot hove been in the 

5X" t'™'"**' of ,ime in order ,o ** 

teleprocessing. 0 ™ de!irob ' e ^ proe « si "9 s ^ e " s 


241 




OPERATING SYSTEM 


REQUIREMENTS CHECKLIST I Reference 





















1.3.2.1 STRUCTURE DEFINITION 


Reference: 

1. While frequently employed for evaluation, these criteria are reneiy 
specified. However it may be necessary to specify certain of these 
criteria based upon anticipated file design requirements. 

2. A sequential structure is one in which the data elements are all of 
equal rank. This method can be used in support of data which can be 
grouped into data elements that are an entity within themselves. 

3. Hierarchical structures provide the capability to structure a file based 
on a ranking scheme usually related to a specific type of logical group 
relationship. An example of this type of data could be a file contain¬ 
ing a logical ranking such as: nation, political subdivision, counties, 
major cities, etc. 

4. The indexed structure may be applied to either the sequential or hier¬ 
archical structure method and can be used to selectively locate data 
elements within a file. 

5. The ring and list type of file structure are closely related. Each data 
element contains the address of the next successive data element 
within a file. The difference in the two structures is that the last 
data element in a ring contains the address of the first data element, 
whereas the list does not. A ring structure thus allows the user tr 

ead a total sequence of data elements starting with any element within 
the ring. 

6. This criterion is highly desirable for a processing system where the 
retrieval elements are either random or unpredictable. In this struc¬ 
ture retrieval time is minimized regardless of the data fields queried. 
However, this type ot structure also requires an extremely complex 
file updating technique. 

7. Repetitive data elements are those which have a number of entries 
under c single data label. For example, in a bank account record, 
deposits and/or withdrawals tend to be repeating entries. 


1.3.2.2 SPACE ALLOCATION 
Reference: 

1. The specification of these criferio is dependent upon the 
hardware configuration. 
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REQUIREMENTS 


OPERATING SYSTEM 
REQUIREMENTS CHECKLIST 


1.3.2.3 

INPUT TRANSACTION PROCESSING 

(a-c) The system must provide input transaction processing 

facilities that allow: 

(a) 

input data definition, 

(b) 

input data validation, 

(c) 

input data alteration. 

(d-e) The system must allow the following types of input 

formats: 


(d) 

(*) 

pre-established, 

self-defining. 

(f-i) The system must provide the following types of input 

data validation: 

(0 

equal value compar jn, 

(g) 

range verification. 

00 

(i) 

masked comparison, 
sequence checking. 

(j-l) The system must provide the following types of inpu* 

data alteration: 

(i) 

00 

automatic truncation/padding, 
encod i ng/decod ing, 
constant factor modification. 

(i) 

(m-o)The system must recognize the following input data 

terminator; 


(m) 

standard (embedded) field. 

(n) 

special characte.-(s). 

(o) 

physical media markers. 
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1.3.2.3 INPUT TRANSACTION PROCESSING 


Reference: 

1. These criteria should be specified for all data management systems. 

2. In many cases the structure of the input to be received can be 
established in advance. At other times the method in which the user 
receives the input precludes effective data structuring. 

The pre-established format is useful for fixed record input media such 
as punched cards, magnetic tape, etc. The self defining format is 
usually best for teleprocessing based transactions. 

3. The ability to truncate or pad data is useful in forcing data conformity. 
Encoding can be useful in decreasing storage requirements, while 
decoding is the reverse but allows the user to make abbreviated 
references. Constant factor modification allows input data values 

to be*modified by a data value. 

4. Input terminators are used to signal the end of the input data to be 
processed. Each of these techniques has its advocates, and no part¬ 
icular method is favored. 
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OPERATING SYSTEM 


REQUIREMENTS 























1.3.2.4 LOGICAL RECORD MAINTENANCE 


Reference: 

1. Logical query provides the user the capability to update records 
based upon a specified condition being satisfied. An example of 
this would be the statement "delete all records after a given calendar 
date" or "refain all records between two given calendar dates". 

2. Update by multi-record logic provides the user the capability to 
update records by referencing another record or records as control. 

3. A system that provides subordinate files should have the capability 
to automatically update these filer when an update is performed on 
the master file to which they are subordinate. 


1.3.2.5 INTERACTIVE FILE MAINTENANCE CONTROL 
Reference; 

1. These criteria are highly desirable for a data management system 
that supports interactive maintenance from on-line terminals. This 
feature provides a user with the capability to override established 
data validation conditions or data definition in an on-line interactive 
mode. 


247 


OPERATING SYSTEM 


REQUIREMENTS 


REQUIREMENTS CHECKLIST 


1.3. 2 .6 FILE REORGANIZATION 

(a-c) The system mus* allow the following methods of re¬ 
structuring: 

(a) field addition, 

(b) deletion, 

(c) reordering. 

(d-e) The system must allow the following types of merging: 


Reference 


1 


(d) 

(e) 


intra-file, 
inter-file. 


















1.3.2.6 FILE REORGANIZATION 
Reference: 


1. These methods ore frequently found In data management systems 
and are desirable for meeting varying file design requirements, 

2. Infra file merging involves the changing of the internal structure of a 
file by restructuring and merging records within the file. 

inter-file merging consists of merging different files into a single file 
structure which will better satisfy a particular application. This allows 

the user to build master files of related data from existing singularly 
used files. ' 
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